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1  Introduction 

1.1  Task  Description 

The  Marine  Corps  is  transitioning  into  a  new  form  of  logistics  support.  Traditional 
means  of  support  are  being  amended  to  take  advantage  of  computer,  sensor  and 
communications  technologies  to  provide  efficiencies  in  combat  service  support.  This 
project  will  review  what  technologies  are  available  to  support  the  Marine  Corps  logistics 
transformation  effort  and  how  these  technologies  can  be  implemented  in  the 
maintenance  and  supply  (components  of  CSS)  of  ground  equipment. 

To  conduct  a  review  of  the  sources  of  autonomic  logistics  data,  the  requirements  of 
what  that  data  should  be,  the  timeliness  or  required  “pull”  of  such  data,  its  transmission 
means  in  garrison  and  in  the  field  (afloat  or  ashore),  the  availability  of  current  or  planned 
logistic  systems  to  receive  data,  and  what  Decision  Support  Tools  (DSTs)  would  be 
used  to  transform  the  data  into  the  necessary  information  by  which  timely  and  long-term 
support  decisions  can  be  made  as  part  of  Total  Ownership  Cost  (TOC)  of  the  LAV 
family  of  vehicles.  The  study  will  recommend  standards  for  the  Corps  to  apply  across 
the  existing  and  planned  end  item  regarding  diagnostic  sensor  integration  as  designated 
by  the  Sponsor  and  provide  a  programmatic  roadmap  on  how  autonomic  logistics  data 
can  support  future  maintenance  and  supply  side  USMC  logistics  systems. 

The  draft  Statement  of  Work  (SOW)  provided  by  the  Sponsor  for  this  effort  was 
narrowed  in  scope  to  focus  on  one  major  end  item.  PSU  performers  will  address  the 
USMC  logistic  efforts  with  all  of  the  known  functions  and  components  and  develop  a 
support  template  for  sea-based  logistics  to  the  selected  end  item.  PSU  proposes  to 
evaluate  the  LAV  family  of  vehicles  as  the  one  (1)  selected  USMC  end  item.  By 
focusing  on  the  feasibility  of  integrating  diagnostics  on  one  (1)  representative  system, 
this  effort  can  then  by  analogy  and  similarity  address  the  broader  requirements 
articulated  in  the  SOW. 

This  effort  is  broken  down  into  the  following  tasks  that  will  be  executed  concurrently: 

Task  1:  Literature  Review  Task  1.1:  Review  all  pertinent  USMC  logistics  information  on 
one  (1)  selected  USMC  end  item.  This  will  include  reviewing  legacy  logistics  support 
systems,  current  operating  procedures  and  future  support  concepts  to  include  the 
Integrated  Logistics  Capability  (ILC)  for  incorporation  on  the  selected  system. 

•  Task  1.2:  Review  of  technologies  that  do  or  could  support  maintenance 
diagnostics  for  the  selected  USMC  equipment. 

o  Task  1.2.1:  Review  of  data  processing  technologies  that  do  or  could 
support  predictive  maintenance  actions  and/or  failure  modes  on  the 
selected  USMC  end  item. 

o  Task  1 .2.2:  Review  trend  analysis/decision  technologies  that  would  assist 
USMC  logistics  managers  in  initiating/maintaining  end  item  reliability 
situational  awareness. 
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Task  2:  Maintenance  Data  Implications.  Review  one  selected  USMC  end  item. 
Selected  based  on  span  of  life-cycle  acquisition  stages. 

•  Task  2.1:  Review  what  types  of  maintenance  data  that  is  currently  being 
generated.  Review  the  sources  of  this  data,  means  of  data  generation,  how  the 
data  is  stored/catalogued/reviewed/acted  upon. 

•  Task  2.2:  Review  the  selected  end  item  for  the  types  of  sensors/diagnostic  tools 
needed  to  facilitate  system  diagnostics/failure  analysis. 

•  Task  2.3:  Based  on  the  results  of  tasks  2.1  and  2.2,  recommend  a  standard 
maintenance  data  protocol  for  USMC  end  items.  The  recommended  approach 
will  include  the  following: 

o  What  data  is  required? 
o  How  the  data  will  be  generated/stored/used. 

o  Recommendations  on  what  data  system  and  communication  technologies 
are  available  to  implement  the  approach, 
o  A  recommendation  on  what  data  representation  and  data  recognition  tools 
are  available  to  transform  data  streams  into  useable  information. 

Task  3:  Logistics  Systems  Information.  Based  on  results  of  tasks  1  and  2,  review  the 
suitability  of  current  and  future  logistics  systems  to  use  the  maintenance  information 
generated  to  make  logistic  support  decisions  for  the  selected  USMC  end  item  and  future 
systems. 

•  Task  3.1 :  Determine  the  quantity/quality/timeliness  of  information  to  be  used  at: 

o  The  unit/end  item  level 

o  The  Marine  Expeditionary  Brigade  (MEB)  level 
o  The  HQMC/SYSCOM/MCLC  level 

•  Task  3.2:  Review  candidate  decision  tool  technologies  and  recommend  which 
are  most  suitable  for  implementation. 

Task  4:  Establish  Universal  Data  Support  Requirements. 

•  Task  4.1:  Identify  data  support  functions  for  multi-sensor  prognostics  integration 
for  the  selected  end  item. 

•  Task  4.2:  Recommend  candidate  web  based  technologies  to  facilitate  multi¬ 
sensor  prognostic  integration  for  the  selected  end  item. 

Task  5:  Identify  Critical  Path  and  Risks  for  One  (1)  Candidate  System.  Interpret  and 
correlate  the  results  of  tasks  1-4  and  depict/present  the  information  in  a  way  that 
identifies  a  critical  path  for  implementation  of  a  USMC  Autonomic  Logistics  Support 
System  by  FY  2008. 


1.2  Envisioning  IDGE 

We  envision  an  IDGE  system  as  the  driver  for  the  tasks  we  must  engage  in.  These 
include  the  identification  of  data  requirements,  identification  of  tools  and  techniques  that 
may  facilitate  the  eventual  creation  and  deployment  of  such  a  system,  and  the 
organizational  constraints  e.g.  OA  processes  being  worked  on  as  part  of  other  efforts 
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under  way  at  the  Marine  Corps.  The  envisioned  system  should  also  take  into  account 
current  work  in  the  areas  of  autonomous  logistics,  condition-based  maintenance,  and 
respond  to  trends  such  as  sea-basing.  Using  this  approach  is  useful  because  it  allows 
members  of  the  research  team  an  opportunity  to  develop  a  shared  vision,  one  that  can 
then  permeate  the  distributed  efforts  of  the  team  members.  The  vision  also  allows  a 
means  of  communicating  with  the  clients  and  potential  users.  It  becomes  a  strawman 
that  can  guide  discussion,  operationalization  and  debate  about  the  form  the  system  will 
assume  in  the  future. 

1.2.1  A  Preliminary  Definition 

The  proposed  IDGE  system  is  a  means  to  accomplishing  efficient  and  autonomous 
Condition  Based  Maintenance  (CBM).  It  is  meant  to  be  a  bridge  between  the  actual 
physical  sensors  installed  on  deployed  ground  equipment  and  the  Operational 
Architecture  (OA )/  logistics  processes  involved  in  supporting  the  Marine  Corps 
operations  [Appendix  1],  The  diagnostic  system  attempts  to  process  the  information 
from  the  sensors  intelligently,  and  to  optimally  facilitate  and  automate  the  triggering  of 
the  appropriate  logistics  processes.  This  concept  is  called  Autonomic  Logistics  (AL). 
Additionally,  the  diagnostic  system  also  attempts  to  integrate  the  multiple,  complex, 
stove-piped  processes  in  the  logistics  chain  with  a  view  to  making  them  cross  functional 
and  efficient.  This  concept  is  termed  as  Integrated  Logistics  Capability  (ILC). 

1.2.2  The  Boundaries  around  IDGE 

The  IDGE  system,  thus,  is  an  intermediary  between  the  ground  equipment  sensors  and 
the  OA  processes.  Hence,  these  can  be  considered  as  the  boundaries  that  scope  the 
system. 
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1.2.2. 1  Sensor  Architectures 


The  Figure  1.1  shows  the  conceptual  depiction  of  the  sensor  architecture  on  an  LAV 
and  connectivity  to  the  Integrated  Data  Environment  [2], _ 


Multi-Platform  System 

AAAV,  AAV,  LAV,  M1A1, 
MTVR,  HMMWV,  etc 


Integrated  Data 
Environment  (IDE) 


Communications  System: 
EPLRS,  UHF,  VHF,  SATCOM, 
Commercial 


ixistino  onboard  computers  and  sensors. 

he  level  of  complexity  depends  upon  the 
lost  system’s  design. 


Autonomic  Processing  Module. 

Collects,  Prepares,  and 
Transmits  Data. 


Figure  1 .1 :  Sensor  architecture  depiction  [2] 

The  types  of  data  transmitted  from  the  LAV,  via  the  communications  system,  include 
location,  fuel  levels,  system  health  and  ammunition  levels.  GPS  satellites  will  primarily 
serve  in  tracking  the  location  of  the  LAV.  Fuel  levels  and  system  health  can  be  gauged 
from  on  board  computers  and  sensors  that  are  constantly  measuring  multiple  physical 
parameters  such  as  vibration,  stress  and  strain,  pressure,  acceleration  etc  which  are 
then  encoded  and  wirelessly  transmitted  to  the  active/  passive  sensor  signal  analyst  - 
entry  point  to  the  IDGE  system.  These  parameters  are  then  compared  with  threshold 
values  stored  in  a  database  for  the  diagnosis/  prognosis  of  the  component. 

Wireless  sensors  provide  new  opportunities  to  foster  the  push  to  develop  prognostics/ 
diagnostics  for  the  ground  equipment.  Reference  [10]  gives  further  information  on  the 
different  wireless  sensing  topologies  that  can  be  employed. 


1. 2.2.2  Operational  Architecture  Processes 

The  Marine  Corps’  existing  supply  chain  includes  more  than  200  individual  systems  to 
support  ground  logistics,  called  Automated  Information  Systems  (AISs),  with  almost  no 
integration  among  them  [3].  The  same  processes  were  used  to  acquire  and  manage 
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virtually  all  types  of  inventory,  regardless  of  an  item's  strategic  importance.  Demand- 
signal  information  was  not  shared  up  and  down  the  supply  chain,  nor  was  total-asset 
visibility  available  for  such  items  as  inventory  and  equipment.  This  lack  of  information 
meant  the  USMC  needed  a  lot  of  inventory  per  requirement  that  tied  up  significant 
capital  resources  that  could  be  used  for  other  strategic  purposes,  such  as  new-weapons 
development.  AISs  utilize  a  combination  of  in  house  developed  application  software, 
Government  Off-the-Shelf  (GOTS)  products,  and  Commercial  Off-the-Shelf  (COTS) 
products  [4].  Many  of  these  systems  were  originally  designed  to  support  stove-piped 
logistics  functions  and  processes  of  the  1960’s.  As  time  passed,  lack  of  an  overall 
development  plan  created  multiple  systems  with  overlapping  capabilities.  These 
systems  utilize  a  wide  range  of  information  technology,  much  of  which  is  aging  and 
difficult  to  integrate.  Integration  has  been  accomplished  in  the  past  through  a  rapidly 
increasing  number  of  point-to-point  interfaces,  which  are  difficult  to  maintain  over  time 
and  unreasonably  complicated  by  the  unplanned  data  environment. 

The  consolidation  of  these  legacy  information  systems,  currently  used  to  support  ground 
logistics,  by  migrating  to  a  smaller  number  of  systems  without  loss  of  functionality,  is  the 
primary  objective  of  the  USMC.  The  migration  and  retirement  strategies  for  transition 
from  a  very  large  number  of  legacy  applications,  data  stores,  and  interfaces  to  a  much 
smaller  number  of  primarily  COTS-based  systems  in  a  shared  data  environment  is 
called  System  Realignment  and  Categorization/Consolidation  (SRAC)  and  is  shown  in 
the  figure  below. 


Figure  1.2:  ILC  Information  System  Transformation  [4] 

A  detailed  operational  architecture  has  been  delivered  to  the  USMC  by  Sapient,  a 
business  and  technology  consultancy,  which  reduces  the  200-plus  logistics  applications 
to  a  much  smaller  number  of  integrated  web  and  wireless  applications  [3],  The 
anticipated  outcomes  are  a  leaner  support  structure  that  will  free  up  1 ,800  Marines  from 
logistics  duties  and  make  them  available  for  other  purposes;  faster  deployment 
capability  resulting  from  a  20  to  70  percent  reduction  in  the  tonnage  it  needs  to  ship;  a 
one-time  reduction  in  inventory  of  45  to  61  percent;  inventory  cost  savings  of  between 
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$125  million  and  $180  million  every  year;  and  a  35  to  50  percent  reduction  in  order 
cycle  time  for  products  and  services. 

The  U.S.  Marine  Corps  is  also  currently  working  with  content  management  software 
vendor  Enigma  Inc.  in  an  effort  to  streamline  OA  processes  including  maintenance  and 
repair  work  on  LAVs  that  are  designed  for  battlefield  use  [1],  The  Marines  plan  to  use 
the  Enigma  3C  Platform  software  to  develop  a  series  of  interactive  technical  manuals  so 
LAV  crews  can  diagnose  problems  and  make  in-the-field  repairs  to  their  vehicles.  The 
electronic  manuals  will  provide  online  access  to  service  information  and  parts  catalogs 
for  all  LAV  models.  In  addition,  the  software  will  be  linked  to  onboard  diagnostics  and 
configuration  management  systems,  as  well  as  parts-ordering  and  inventory 
management  applications.  These  links  will  let  the  Marines  stockpile  spare  parts  for  the 
LAVs  and  then  rapidly  deliver  them  to  vehicle  crews  as  needed. 


1.2.3  Ari  Envisioned  System  for  IDGE 

Based  upon  the  descriptions  of  the  system  boundaries,  the  overall  picture  of  an 
envisioned  IDGE  system  would  resemble  Figure  1.3  below  [9]. 


Figure  1.3:  Overall  system  architecture  [9] 

The  point  of  connectivity  between  the  sensor  architecture  and  the  IDGE  system  is  the 
sensor  signal  analyst,  who  could  be  an  automated  system  or  a  human.  The  sensor 
signal  parameters  are  retrieved  and  then  compared  with  threshold  values,  that  are 
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predetermined  for  each  component  in  the  LAV.  Depending  on  the  result,  the  appropriate 
action  is  taken.  These  threshold  values  can  take  the  form  of  the  active  lifetime  of  a 
component,  allowable  stress  values  etc.  If  the  retrieved  values  are  exceeding  or  close  to 
exceeding  the  failsafe  limits  (typically  fixed  at  10%  below  ultimate  thresholds),  then  the 
request  management  process  in  the  set  of  OA  processes  has  to  be  triggered.  A 
corrective  action  in  the  form  of  repairs  or  replacements  is  warranted.  Further,  when 
such  a  corrective  action  is  taken,  it  needs  to  be  recorded  and  the  component  history 
database  has  to  be  updated  to  reflect  the  change.  Typically,  this  involves  resetting  the 
threshold  values  for  the  component. 

The  corrective/  maintenance  action  can  be  carried  out  by  any  of  three  levels  of 
maintenance,  and  it  is  imperative  that  the  escalation  procedures  be  carried  out  to 
ascertain  which  level  handles  the  problem.  This  is  done  on  the  basis  of  an  SMRC  code, 
which  is  assigned  to  the  problem  by  the  first  troubleshooters/  analysts.  A  description  of 
these  3  hierarchical  levels  is  explained  in  Chapter  3.3.2. 

The  detailed  functionalities  of  the  IDGE  system  along  with  the  personnel/  systems 
interacting  with  it,  shall  be  manifested  in  the  form  of  uses  cases  and  actors,  respectively, 
using  the  visual  modeling  tool  of  Rational  Rose. 
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2  Marine  Corps  (MC)  Background  Information 

In  order  to  achieve  the  goal  of  this  project,  the  team  has  to  thoroughly  understand  the 
current  and  developing  systems  in  USMC.  This  initiated  a  survey  of  literature  for  the 
following  systems  -Operational  Architecture,  SCOR  model,  Autonomic  Logistics  (AL), 
GCSS-MC  and  Integrated  Logistics  Capability  (ILC).  The  detailed  summary  related  to  all 
these  can  be  found  in  Appendix:  1. 

The  ‘to-be’  logistics  system  for  the  USMC  aims  to  realize  the  following: 

-  Provide  overall  direction  to  the  re-engineering  efforts  and  align  the  various  systems 
by  making  the  necessary  tradeoffs  between  requirements,  solutions  and  funding  so 
as  to  ensure  optimal  results. 

-  Ensure  that  the  requirements  of  the  War-fighter  are  translated  into  system  and 
functional  requirements. 

Ensure  that  the  developed  solution  meets  the  requirements  and  forms  the  best  fit 
for  the  Marine  Corps  in  terms  of  reliability,  robustness,  economy  and  culture. 

Developing  a  blue  print  by  identifying  the  requirements  as  well  as  solutions  calls  for  a 
systematic  and  standardized  approach.  The  requirements  have  to  be  identified  along 
the  three  fundamental  perspectives  -  operational  view,  systems  view  and  the  technical 
view.  Aligning  the  system  along  all  these  three  views  will  ensure  uniformity  and 
consequently  inter-operability  within  the  different  organizations  of  the  USMC. 

The  architecture  can  therefore  be  described  as  a  combination  of  these  three  different 
views.  The  operational  architecture  view  is  a  description  of  the  tasks  and  activities, 
operational  elements,  and  information  flows  required  to  accomplish  or  support  a  mission. 
The  systems  architecture  view  is  a  description  of  systems  and  their  interconnections 
providing  for  or  supporting  the  war-fighting  functions.  The  technical  architecture  view 
describes  the  enabling  technologies  and  concepts  that  govern  the  arrangement, 
interaction  and  interdependence  of  the  different  systems.  The  review  of  relevant 
literature  shows  that  the  operational  architecture  view  has  been  developed  for 
application  across  the  USMC. 

The  operational  architecture  description  identifies  the  customer  as  the  ultimate 
consumer  of  the  products/services.  The  customer’s  main  responsibilities  include 
demand  generation,  operator  level  maintenance  and  accounting  for  their  resources. 
Demand  could  be  reactive  such  as  unscheduled  maintenance  or  forecasted  such  as 
scheduled  inventory  replenishment.  The  customer  requests  are  passed  on  to  a  single 
entity  through  manual  or  autonomous  modes.  This  entity  (SI)  is  responsible  for  the 
detailed  logistics  chain  processes  including  managing  orders,  sourcing  and  delivery. 
The  sourcing  and  transportation  decisions  can  be  made  by  SI  only  if  real-time  data 
about  the  requirements  and  the  potential  source  of  supply  across  the  enterprise  is 
available.  This  requires  sharing  of  data  among  different  entities  with  SI  and  can  be 
enabled  by  a  Shared  Data  Environment  (SDE)  [Refer  Figure  11.5  in  Appendix:  1],  This 
facilitates  the  flow  of  data  throughout  the  enterprise  and  provides  visibility  of  the  assets 
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in  transit  and  in  processing.  It  also  renders  real-time  or  near  real-time  analysis  of  the 
information  at  each  node  within  the  logistics  chain.  Refer  Appendix:  1  for  a  detailed 
description. 

The  conceptual  ideas  discussed  above  emerge  from  the  philosophy  behind  the  ILC  that 
is  to  enable  the  maintenance  of  a  shared  data  environment  and  further  enterprise-wide 
planning  based  on  real  time  and  accurate  information,  so  that  the  holistic  metrics  of  a 
global  supply  chain  can  be  optimized.  The  ILC  aims  to  transform  the  mode  of 
operations  within  the  USMC  to  meet  the  challenges  of  tomorrow.  The  transformation 
strategy  is  based  on  best  practices  within  the  industry  and  would  provide  a  framework 
for  the  execution  of  agile  and  effective  logistics  support.  The  key  enabler  of  the  ILC 
concepts  is  information  technology.  The  ILC  thus  envisions  a  family  of  systems  that 
provides  information  interoperability  across  the  combat  support  functions  and  between 
combat  support  and  the  command  &  control  functions  in  support  of  the  joint  war  fighter. 

Thus  the  GCSS  would  be  the  war  fighter’s  tool  to  capture  essential  data,  transform  it  to 
usable  information  and  gain  information  superiority  to  the  success  of  maintaining  force 
readiness  and  winning  nation’s  conflict.  It  would  be  a  flexible  tool  that  would  enable  a 
seamless  transition  between  peacetime  and  contingency  operations. 

The  essential  attributes  envisioned  within  the  GCSS  are  listed  below: 

-  Common  operating  environment  for  all  the  elements  (computers)  that  will  help 
overcome  the  incompatibility  of  different  operating  systems. 

-  Common  interface/screen  that  will  enable  any  authorized  user  to  comprehend  the 
information,  this  would  also  reduce  the  training  required. 

-  Availability  of  all  war  fighter  functions  from  a  single  workstation.  Integration  of 
information  across  functional  areas,  combat  support  and  command  &  control. 
Common  services  such  as  printer,  sound  and  communication  interfaces  with  the 
COE,  forms  and  report  generators,  database  searches,  data  extraction  and 
business  process  servers. 

Robust  communications  infrastructure. 

-  Access  to  the  GCSS  should  be  available  from  any  geographic  location. 

The  GCSS  would  merge  with  the  Global  Command  and  Control  Systems  (GCCS) 
wherein  GCSS  would  enable  commanders  to  provide  military  information  rapidly  to  the 
National  Command  Authorities  (NCA)  and  to  other  supporting  commands.  The  GCCS 
concentrates  heavily  on  the  operations  while  the  GCSS  would  focus  on  the  combat 
support  or  logistical  requirements  of  the  war  fighter.  The  convergence  of  both  these 
systems  will  provide  situational  awareness  via  near  real-time  view  of  the  battlespace  for 
any  mission. 
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3  Maintenance 

3.1  Overview  on  Maintenance 

3.1.1  Maintenance 

Maintenance  is  an  essential  part  for  any  system/plant  for  sustainability  of  the 
system/plant.  Monitoring  plays  a  significant  role  in  maintenance.  Depending  upon  the 
type  of  maintenance  requirements  (scheduled,  anticipatory  or  critical)  monitoring  and 
maintenance  efforts  are  closely  inter-related. 

Figure  3.1  provides  features  of  maintenance  related  to  monitoring. 


3.1.2  Various  Maintenance  types  related  to  Monitoring 


T  ime  based 


Time  based 


Time  based 


Time  based 


Emergeitcy 


Machine  based 
(monitor) 


Machine  based 
(monitor) 


Machine  based 
(monitor) 


Figure  3.1:  Types  of  Maintenance  related  to  monitoring 
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The  following  list  explains  in-detail  the  various  types  of  maintenance  [12]: 

1)  Maintenance:  examines  the  system  operations  efficiently;  replaces  the 
features/component(s)  that  looks  like  or  soon  to  be  worn  out  and  to  bring  them  to 
“as-new”  condition.  It  includes  repairing,  replacing  and  servicing. 

2)  Breakdown  maintenance:  also  called  as  “failure  maintenance”.  This  type  of 
maintenance  comes  into  action  after  the  system/component(s)  have  failed.  It  is 
an  unplanned  event  (maintenance)  which  results  in  high  cost  and  also  not 
appealing  to  the  maintenance  personal  because  of  the  inconvenient  work  timings. 

3)  Condition-based  maintenance:  refer-  proactive,  preventive  and  predictive 
maintenance. 

4)  Corrective  maintenance:  This  maintenance  is  based  on  “performance 

monitoring”.  When  performance  of  a  system  drops,  a  certain  amount  of 
maintenance  has  to  be  ensured  in  order  to  maintain  the  system  in  its  “best 
condition”.  This  type  of  maintenance  is  expected  and  has  to  be  planned  in 
advance.  It  could  be  considered  as  a  combination  of  breakdown  (unplanned)  or 
reactive  maintenance. 

5)  Failure  maintenance:  refer-  breakdown  maintenance. 

6)  Fixed-time  maintenance:  refer  -  reactive  and  time-based  maintenance. 

7)  Improvement  maintenance:  refers  to  the  maintenance  that  involves  modifications 
and  re-designing  within  the  system. 

8)  Machine-based  maintenance:  It  relates  to  maintenance  before  any  breakdown 
i.e.,  before  any  deterioration  or  after  the  early  stages  of  failure  become 
detectable. 

9)  On-condition  maintenance:  It  is  a  combination  of  proactive,  preventive  and 
predictive  maintenance. 

10) Planned  (or  schedule)  maintenance:  In  a  system,  this  type  of  maintenance  is 
considered  to  be  essential  and  is  scheduled  to  occur  during  systems  operation. 
For  example,  a  maintenance  manager  and  team  are  appointed  and  they  operate 
at  the  most  convenient  time. 

1 1 )  Predictive  maintenance:  By  able  to  predict  the  future  deterioration  of  a 
component  from  past  information,  this  type  of  maintenance  will  be  able  to 
determine  the  most  convenient  time  for  maintenance  to  be  undertaken.  This  is 
done  either  by  examining  the  component  at  frequent  intervals  or  by  using 
continuous  monitoring  methods. 
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12) Preventive  (or  preventative)  maintenance:  By  taking  a  deteriorating  current 
situation  into  action,  this  type  of  maintenance  is  undertaken  to  prevent  any 
further  worsening.  It  requires  a  certain  amount  of  monitoring  to  provide  sufficient 
evidence  to  consider  action  at  the  best  time;  however,  it  could  be  time  based. 

13) Proactive  maintenance:  By  monitoring  components  which  cause  or  prone  to  fail 
-  rather  than  considering  early  signs  of  failure  -a  suitable  maintenance  action 
could  prevent  any  commencement  of  deterioration.  It  is  considered  to  be  the 
most  valuable  monitoring  technique  available. 

14) Reactive  maintenance:  This  type  of  maintenance  is  more  predominant  for 
replacing  the  components  that  have  already  failed.  It  can  be  acceptable. 

15) Reliability-centered  maintenance:  It  is  considered  to  be  a  machine-based 
maintenance,  which  encompasses  all  planned  maintenance  under  the 
examination  of  the  complete  failure  of  complex  component.  It  is  based  on  the 
inherent  reliability  of  each  item  of  equipment  when  used  in  its  correct  operating 
state. 

16) Time-based  maintenance:  sometimes  called  as  “fixed-time  maintenance”.  From 
past  experience,  and  from  careful  analysis  or  guesswork  if  the  system  is  new,  a 
schedule  of  maintenance  is  organized  so  that  at  certain  fixed  intervals  each  part 
of  the  system  is  appropriately  maintained. 

17) Total  productive  maintenance:  This  idea  of  maintenance  is  designed  to  provide  a 
continuous  improvement  in  production.  In  general,  production  drops  with  time 
due  to  deterioration  of  the  component  and  lack  of  personal  interest.  The 
objective  of  this  maintenance  is  to  promote  interest  and  involvement  from  a 
variety  of  personnel  in-group  activity.  This  will  lead  to  consider  maintenance 
seriously  and  will  include  functions  like  routine  inspection,  cleaning  and 
equipment  problems  to  be  solved  in  a  cooperative  manner. 

18) Unplanned  (or  unscheduled)  maintenance:  Suppose  a  component  fails  to 
function  due  to  some  fault,  then  an  emergency  team  will  be  hurriedly  formed  and 
asked  to  put  the  matter  right  immediately,  however  inconvenient  it  may  be.  It  is 
run  on  emergency  lines. 

For  our  study  we  deal  with  three  classes  of  maintenance  practices: 

1.  Scheduled  (Refer  No.  10  in  the  above  list) 

2.  Anticipatory  (Refer  No.  12  in  the  above  list) 

3.  Critical  (Refer  No.  2  in  the  above  list) 

Literature  abounds  with  information  on  Scheduled  and  Anticipatory  maintenance.  The 
most  critical  part  of  these  is  how  the  maintenance  plans  are  implemented.  Therefore, 
we  do  not  go  to  the  background  literature  on  these  two.  However,  in  our  framework  we 
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will  discuss  how  these  needs  to  be  incorporated  in  the  MC  maintenance  functions.  In 
the  next  chapter,  we  detail  our  science-based  approach  for  anticipatory  maintenance. 


3.2  Anticipatory  Maintenance:  Research  based  Preliminaries 

3.2.1  Introduction  and  Definitions 

Anticipatory  Maintenance  (AM)  comprises  of  Monitoring,  Diagnosis,  Prognosis  and 
Control.  The  word  diagnosis  is  defined  as  a  judgment  that  is  the  result  of  the  act  of 
discovering  the  current  nature  of  a  fault  by  making  a  careful  examination.  Prognosis  is 
a  judgment  about  the  future  status  based  on  available  information  and  experience.  To 
be  intelligent  is  to  possess  powers  of  learning,  reasoning,  and  /  or  understanding, 
especially  to  a  high  degree  [16]. 

Desired  capabilities  of  a  system  that  can  accurately  diagnose  the  current  equipment 
conditions  and  make  predictions  about  its  future  behavior  are: 

1 .  On-line  Monitoring  of  an  equipment  with  minimal  supervision 

2.  Detection  of  a  fault  initiation  before  catastrophic  breakdown  occurs 

3.  Diagnosis:  Identify  the  type  of  a  failure  and  perform  reasoning  /  interpretation  of 
the  current  condition 

4.  Prognosis:  assess  the  evolution  of  the  faulty  condition,  predict  time-to-failure  and 
invoke  corrective  action  if  necessary. 

We  identify  the  above  four  as  the  key  issues  and  efforts  that  need  to  be  critically 
examined  for  building  an  Anticipatory  Maintenance  Framework  for  Marine  Corps 
Ground  Equipment.  Several  disjoint  disciplines  such  as  digital  signal  processing  (DSP), 
wavelet  theory,  and  pattern  recognition  including  neural  networks,  multi-sensor  fusion, 
and  statistical  forecasting  methods  are  critical  to  such  a  system  development.  We 
consider  a  LAV  as  an  example  to  build  the  Integrated  Diagnostics  framework.  LAV’s  are 
equipped  with  on-board  sensors  and  we  can  assume  (we  relax  this  assumption  when 
we  build  the  IT  framework)  that  the  processing  of  sensor  data  is  done  by  on-board 
processors. 

Figure  3.2  shows  the  high-level  systematic  framework  of  AM  without  considering 
interfaces  to  AL.  At  this  level  AM  composes  of  six  basic  steps:  (1)  Sensor  data 
acquisition,  (2)  Exploratory  analysis,  (3)  Signal  preprocessing,  (4)  Sensor  data 
representation,  (5)  Diagnosis,  and  (6)  Prognosis. 
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Figure  3.2:  Schematic  Diagram  of  AM 

Diagnosis  can  be  performed  through  the  utilization  of  on-line  sensing  devices.  The 
required  information  on  the  present  condition  of  the  LAV  is  collected  (monitoring)  using 
different  types  of  sensors  such  as  force,  vibration,  battery  condition,  and  acoustic 
emission,  etc.  In  a  complex  system  such  as  LAV,  a  suite  of  different  types  of  sensors  is 
often  employed  and  they  provide  multiple  monitoring  features.  A  multi-sensor  fusion 
technique  can  be  employed  in  such  a  case  to  remove  redundant  information  and  to 
combine  imprecise  information  from  multiple  sensors  to  obtain  accurate  and  concise 
features[16]. 

Exploratory  analysis  is  a  very  important  step  since  it  can  reveal  substantial 
characteristics  of  the  signals  in  advance.  Without  understanding  the  fundamental 
attributes  of  the  signal  under  consideration,  it  is  impossible  to  select  an  appropriate 
signal  representation  scheme  reflecting  the  underlying  dynamics  of  signal  accurately, 
leading  to  poor  diagnosis  and  prognosis  performance  consequently. 

The  right  choice  of  a  representation  scheme  could  not  be  emphasized  less  because  the 
success  of  diagnosis  and  prognosis  depends  on  the  robustness  (accuracy)  of  features 
extracted  out  of  the  signal  representation  scheme.  Effective  sensor  data 
representation  must  be  not  only  matching  with  the  structural  characteristics  of  the 
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signals  under  consideration,  but  also  it  has  to  provide  the  parsimonious  and  accurate 
information  to  be  used  for  fault  (anomaly)  detection  and  prediction.  A  diagnosis  system 
on  an  LAV  equipped  with  an  efficient  feature  extractor  /  compressor  will  be  able  to 
provide  condensed  information  sensitive  to  the  current  condition.  Given  the  features, 
diagnosis  establishes  the  relationship  between  the  monitoring  features  and  the  status  of 
LAV. 

Prognosis  for  an  observed  system  (a  component,  sub-assembly  of  LAV)  requires 
accurate  forecasts  of  the  future  behavior  of  a  particular  component  of  the  LAV.  The 
ability  to  accurately  predict  the  time  evolution  of  the  system  makes  it  possible  to 
determine  the  future  status  of  the  system  and  to  provide  an  indication  of  failure 
precursors,  leading  to  the  enforcement  of  maintenance  actions.  During  the  ongoing 
fault  evolution  process,  initiation  of  a  specific  fault  must  be  detected  and  confident 
prediction  on  the  fault  evolution  in  the  near  future  will  be  required  to  be  made  before  the 
magnitude  of  a  failure-state-index  reaches  maintenance  techniques  that  are 
postmortem  approaches,  an  ideal  AM  will  monitor  LAV  components  continuously 
through  on-line  sensors.  Based  on  the  sensor  data,  AM  will  trigger  the  diagnosis  and 
prognosis  modules  where  current  status  and  remaining  life  of  the  component/sub¬ 
assembly  are  estimated. 

In  developing  the  signal  representation  scheme,  the  following  issues  need  to  be 
addressed: 

1.  How  to  represent  sensor  signals  in  such  a  way  that  the  extracted  features  - 
usually  lie  in  a  transformed  domain  with  respect  to  certain  basis  -  contain 
significant  information  useful  for  the  early  detection  of  the  fatigue  crack  growth 
and  gear  tooth  breakage. 

2.  How  to  obtain  a  set  of  parsimonious  features  which  are  able  to  not  only  capture 
the  transient  nature  of  sensor  signals,  but  also  conserve  both  time  and  frequency 
information  essential  for  prognosticating  the  time  remaining  to  failure. 

3.  How  to  effectively  fuse  and  project  the  multiple  features  into  decision  space  such 
that  derived  judgment  on  the  current  and  future  status  of  a  component  is  reliable 
and  immune  to  environmental  noises. 

4.  How  to  identify  and  track  the  evolution  of  faulty  conditions  and  how  to  establish  a 
prediction  model  therefrom. 
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Signal  Characteristics 

>  Linear 

>  Stationary 

>  Linear 

>  Stationary 

>  Harmonic 
Response 

>  Linear 

>  Non-Stationary 

>  Harmonic 
Response 

>  Nonlinear 
(piecewise  linear) 

>  Non-Stationary 

>  Non-Harmonic 
Response 

Candidate 

Model 

ARMA  type  time 
series  models 

Fourier 

Analysis 

STFT 

Wavelet  Analysis 

Information 

Either  Time  or 
Spectral 
contents 

Frequency 
contents  only 

Both  time  and 
frequency 
(fixed  resolution) 

Both  time  and 
frequency 
(Multi-resolution) 

Table  3.1:  Signal  Characteristics  and  Corresponding  Representation  Scheme 

We  need  to  report  on  the  suitability  of  a  representation  scheme  for  different  sensors 
used  on  the  LAV.  Traditional  techniques  include  time  domain  approaches  and  various 
spectral  analyses.  Often  time,  the  heart  of  these  methods  are  based  on  the  Fourier 
transform.  Since,  most  of  the  time,  deviant  vibration  attributed  to  the  defects  in  one  or 
more  components  of  the  equipment  have  instantaneous  shock  impulses  and  exhibit 
transient  (non-stationary)  nature,  traditional  spectral  analysis  based  on  Fourier  analysis 
is  inadequate  for  the  modeling  of  these  disturbances  that  contaminate  only  a  small 
fraction  of  the  signal  at  a  specific  time  instances.  Wavelet  transform  has  been  proved  to 
be  more  appropriate  for  analysis  of  such  a  signal.  The  Wavelet  Transform  (WT)  is 
capable  of  decomposing  a  signal  into  different  frequencies  with  different  resolutions 
(Multi-resolution  Analysis-MRA)  [16],  i.e.,  it  provides  a  time-scale  (frequency) 
representation  of  the  signal.  The  power  of  the  WT  comes  from  the  fact  that  WT  is  able 
to: 

1 .  Conserve  both  time  and  frequency  information 

2.  Capture  transient  nature  (non-stationary)  of  a  signal  especially  having 
periodic/quasi-periodic  impulse  train 

3.  Conserve  signal  energy  in  the  transform 

4.  Compress  a  signal,  i.e.,  neglect  insignificant  information,  such  that  compact 
representation 

5.  Be  reversible  to  time  domain  without  significant  loss  of  information  content  of  the 
signal. 

Figure  3.3  shows  schematics  of  the  scientific  basis  of  AM.  Each  box  indicates  the  step 
in  the  AM  process  along  with  the  types  of  techniques  applicable. 
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Figure  3.3:  Schematic  Diagram  of  AM 
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3.3  Maintenance  performed  in  Marine  Corps  (MC) 

3.3.1  Introduction  and  categories  of  Maintenance 

Maintenance  is  considered  to  be  a  continuous  and  an  essential  event  that  will 
reduce  the  failure  rate  of  a  component  for  any  kind  of  a  system  or  equipment. 

From  the  MC  point  of  view,  every  unit  performs  maintenance  and  the  unit 
commander  is  responsible  to  ensure  that  maintenance  is  performed  periodically. 
Company  grade  officers  are  the  primary  personal  officers  who  supervise  the 
maintenance. 

Maintenance  Categories: 

Maintenance  is  an  action  taken  to  restore  a  component  in  a  serviceable  condition. 
Functionalities  of  maintenance  are  Inspection,  Testing,  Servicing,  classification  as 
to  serviceability,  repair,  rebuilding  and  reclamation.  It  also  includes  all  supply  and 
repair  action  to  successfully  carry  out  the  mission. 

Maintenance  efforts  are  categorized  into  two  types: 

1.  Preventive  Maintenance  (PM):  Is  performed  to  maintain  the  equipment  in  a 
serviceable  condition  or  to  prevent  the  item  from  becoming  unserviceable. 
PM  is  a  form  of  maintenance  that  the  Marines  routinely  conduct  and 
significantly  enhance  the  equipment  readiness,  thus  improving  unit 
readiness. 

2.  Corrective  Maintenance  (CM):  Is  performed  when  a  component  of 
equipment  no  longer  performs  at  100  percent  of  its  capability.  This  form  of 
maintenance  restores  a  failed  component  back  to  its  serviceable  condition 
and  Marines  with  occupational  specialties  generally  perform  CM. 

The  aforementioned  maintenance  actions  encompass  the  majority  of  unit’s 
(organizational)  maintenance  operations. 


3.3.2  MC  Maintenance  System  Organization 

The  MC  maintenance  system  is  organized  into  three  categories  or  levels  and  five 
sub-levels  or  echelons.  Commanders  are  responsible  to  understand  unit’s  organic 
maintenance  capabilities  as  well  as  their  supported  units. 
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3.3.2.1  Levels  and  Echelons  of  Maintenance  ( EOM ) 

I.  Organizational: 

Maintenance  normally  performed  by  an  operating  unit  on  a  day-to-day  basis  in 
support  of  its  own  operations.  The  organizational-level  maintenance  mission  is  to 
maintain  assigned  equipment  in  a  full  mission-capable  status  while  continually 
improving  the  process.  Organizational-level  maintenance  can  be  grouped  under 
categories  of  "inspections,"  "servicing,"  "handling,"  and  "preventive  maintenance." 

Echelon  1:  (Operator  Maintenance) 

-  Crew  level  servicing  of  vehicles  and  weapons 

-  Includes  standard  servicing  of  equipment,  such  as  preventive  maintenance 
service  checks 

Echelon  2:  (Mechanics/Technicians) 

Performed  by  mechanics  organic  to  the  combat  maneuver  units,  such  as 
infantry  battalions 

Include  fairly  simple  repairs,  such  as  removal  and  replacement  of  major 
items 

II.  Intermediate: 

The  intermediate-level  maintenance  mission  is  to  enhance  and  sustain  the  combat 
readiness  and  mission  capability  of  supported  activities  by  providing  quality  and 
timely  materiel  support  at  the  nearest  location  with  the  lowest  practical  resource 
expenditure.  Intermediate-level  maintenance  includes  limited  repair  of  commodity- 
orientated  components  and  end  items,  job  shop,  bay,  and  production  line 
operations  for  special  mission  requirements;  repair  of  printed  circuit  boards, 
software  maintenance,  and  fabrication  or  manufacture  of  repair  parts,  assemblies, 
components,  jigs  and  fixtures,  when  approved  by  higher  levels. 

Echelon  3  &  4: 

-  Broken  equipment  is  transported  back  to  INTERMEDIATE  repair  resident  in 
MEF  maintenance  battalion,  a  part  of  FSSG  (that  provides  intermediate 
logistics  support  in  general  to  the  entire  MEF) 

-  Battalion’s  five  companies  perform  maintenance  for 

i)  Ordnance  (from  rifles  to  howitzers)  -  Ordnance  Maintenance  Company 
(OMC) 

ii)  Motor  transport  -  Motor  transport  Maintenance  Company  (MTM) 

iii)  Electronics  -  Electronics  Maintenance  Company  (ELMACO) 

iv)  Engineering  equipment  -  Engineer  Maintenance  Company  (EMC) - 

at  the  3rd  echelon  maintenance 

v)  4th  echelon  maintenance  — Battalion’s  General  Support  Maintenance 
Company  (GSM)  do  more  demanding  work  on  major  assemblies  such  as 
engines  and  transmissions. 

The  aforementioned  companies  are  part  of  every  maintenance  Battalion. 
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III.  Depot; 

The  maintenance  that  requires  a  major  overhaul  or  a  complete  rebuilding  of  parts, 
assemblies,  subassemblies,  and  end  items,  including  the  manufacture  of  parts, 
modifications,  testing,  and  reclamation,  takes  place  here.  Depot  maintenance 
serves  to  support  lower  categories  of  maintenance  by  providing  technical 
assistance  and  performing  that  maintenance  beyond  their  responsibility.  Depot 
maintenance  provides  stocks  of  serviceable  equipment  because  it  has  more 
extensive  facilities  available  for  repair  than  are  available  in  lower  maintenance 
activities.  Depot  maintenance  includes  all  aspects  of  software  maintenance. 

Echelon  5: 

-  Maintenance  performed  at  Marine  Corps  Logistics  Base  Albany,  Georgia 
and  Barstow,  California 

Depot  Repairs  include  major  operations  such  as  rebuild  and  overhaul  of  the  entire 
piece  of  equipment. 

Reference  No.  12  states  that  the  following  recommendations  were  made  for  the 
Marine  Corps  Logistics,  2005  -  2010  for  EOM: 

-  Consolidation  of  most  using  unit  supply  responsibilities  at  the  retail  level; 

-  Movement  of  2nd  and  3rd  echelons  of  maintenance  to  the  intermediate  level; 

-  Movement  of  4th  echelon  maintenance  and  secondary  reparable  (secrep) 
management  to  depot  level. 

The  afore-mentioned  recommendations  will  be  considered  in  our  IDGE  study. 


3.3.3  MC  Supply  and  Repair 

This  section  focuses  on  supply  and  repair  in  the  active  part  of  the  Fleet  Marine 
Force  (FMF)  and  the  Marine  Expeditionary  Force  (MEF)  is  the  key  combat  element 
of  the  FMF. 

MEF  is  composed  of  three  major  parts: 

1.  A  ground  division 

2.  An  air  wing 

3.  A  provider  for  Intermediate  Logistics  (Force  Service  Support  Group  - 
FSSG) 

There  are  three  active  MEFs: 

1 .  I  MEF  -  Camp  Pendleton,  California 

2.  II  MEF  -  Camp  Lejeune,  North  Carolina 

3.  Ill  MEF  -  Okinawa,  Japan 
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3.3.3. 1  Repair  and  Supply  in  the  FMF: 

There  are  three  maintenance  levels  and  five  echelons  of  maintenance  (EOM). 
FMF  Repair  is  performed  in  any  of  the  five  echelons  of  maintenance,  four  of  which 
reside  in  the  FMF.  (Refer  section  3.3.2). 

3.3. 3. 2  Equipment  Repair  Order  (ERO): 

When  a  broken  piece  of  equipment,  whether  a  principal  end  item  (PEI),  such  as  an 
Amphibious  Assault  Vehicle  (AAV)  or  a  secondary  repairable,  such  as  an  AAV 
transmission,  is  inducted  into  the  shop,  an  Equipment  Repair  Order  (ERO)  is 
initiated  in  the  Marine  Corps  Integrated  Maintenance  Management  System 
(MIMMS). 

The  ERO  is  a  computerized  tracking  form  for  all  the  actions  done  on  this  piece  of 
equipment  in  a  particular  shop  floor,  including  tracking  time  spent  in  each  phase  of 
repair  -  inspection,  awaiting  shop  space  or  parts,  etc.,  defects  noted  and  man¬ 
hours  expended,  and  parts  requisitioned  and  the  status  quo  of  those  requirements. 
Typically,  complex  repairs  require  one  or  more  repairs  parts  to  replace  the  failed  or 
degraded  equipment.  Each  repair  action  associated  with  an  ERO  will  have  a 
“layette”  or  separate  parts  bin,  where  requisitioned  parts  are  assembled  and 
staged  as,  they  arrive.  When  all  the  parts  required  for  this  particular  equipment 
have  been  received,  the  layette  parts  are  moved  to  the  bench  or  bay  where  the 
broken  equipment  is  located  and  the  repair  action  comes  into  effect. 


MIMMS 


Understanding  ERO 


PET  —  Principal  End  Item 

MIMMS  —  Marine  Corps  Integrated 
Maintenance  Management  System 


Figure  3.4:  Understanding  ERO 
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3. 3. 3. 3  Supply: 

Each  unit  performing  maintenance  keep  small  amounts  of  fast  moving  stock  such 
as  bolts  and  fasteners  in  their  Pre-expended  bins  (PEB). 

For  a  more  substantial  part,  a  unit  however  has  to  go  to  the  Intermediate  level  of 
supply  for  the  MEF,  maintained  by  the  supply  battalion  resident  in  the  MEF. 

The  supply  battalion  is  the  main  provider  of  stocks  for  the  entire  MEF.  It  divides  its 
inventory  into  two  parts: 

i)  Consumables,  held  by  General  Account 

ii)  Repairables,  held  at  the  Repairable  Issue  Point  (RIP) 

These  supplies  are  maintained  and  controlled  by  SASSY  Management  Unit,  or 
SMU  (SASSY  stands  for  Supported  Activities  Supply  System,  the  information 
system  used  to  manage  stocks).  The  supply  battalions  disperse  many  inventories 
all  under  the  single  control  of  SMU. 


3.3.3.4  How  units  request  parts? 

-  Units  requisition  parts  by  placing  orders  through  their  local  Asset  Tracking 
for  Logistics  and  Supply  System  (ATLASS)  computer,  either  through  e-mail 
or  with  daily  submission  of  computer  diskettes  to  the  SMU. 

-  The  SMU  processes  all  requests  in  batch  mode  once  daily  (through  an 
offsite  mainframe  computer),  producing  material  releasing  order  (MRO)  the 
next  morning,  for  picking,  packing,  and  shipping  to  the  requisitioner. 

Items  the  SMU  does  not  stock  or  currently  lacking  may  be  sent  by  the  SMU 
to  the  wholesale  level  of  supply. 

-  SMU  consumables  accounts  can  be  replenished  from  wholesale  supply 
maintained  by  the  Defense  Logistics  Agency  (DLA)  or  by  providers  certified 
by  DLA  (e.g.,  through  the  Prime  Vendor  or  Virtual  Prime  Vendor  initiatives). 

Repairable  stocks  can  be  replenished  by  similar  sources  or  from  the  output  of  the 
General  Support  Maintenance  Company  (4th  echelon). 
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Figure  3.5:  Supply  and  how  units  request  work? 


3.3.4  Maintenance  Systems  used  in  USMC 

This  section  summarizes  document  [17],  which  will  help  us  to  understand 
functionalities  in  MIMMS,  flow  of  information,  maintenance  orders,  its  interfaces  etc. 


3.3.4. 1  Marine  Corps  Integrated  Maintenance  Management 
System  (MIMMS) 

I.  Maintenance  Management: 

Within  the  area  of  maintenance  management,  there  are  eight  sub  functional  areas. 
They  are  as  follows: 

-  Maintenance  Administration 
Personnel  and  Training 

-  Records  and  reports 

-  Publication  control 

-  Equipment  Availability 

-  Preventive  Maintenance  checks  and  services  (PMCS)  and  corrective 
maintenance 
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-  Supply  support  and  maintenance  related  programs 

a)  Equipment  Repair  Order  (ERO): 

-  It  is  a  device  within  the  unit’s  organic  maintenance  capability,  which 
is  used  for  request  modification,  calibration,  corrective  maintenance, 
preventive  maintenance  checks  and  services  and  technical 
inspections  on  all  ground  equipment 

-  Can  also  be  used  to  transfer  work  to  higher  echelons  of  maintenance 
and  for  recording  and  reporting  all  maintenance  that  has  been 
performed. 

b)  Equipment  Repair  Order  Shopping/Transaction  List  (EROSL):  It  has  two 
purposes 

First:  request  repair  parts  associated  with  the  ERO. 

-  Second:  To  input  MIMMS  data  into  the  system,  either  automated  or 
manual. 

c)  Equipment  Records:  There  are  many  records  but  the  two  most  predominant 
ones  are:  preventive  maintenance  checks  and  services  (PMCS)  records  and 
corrective  maintenance  (CM)  records. 

PMCS  record  ensures  that  the  PM  is  systematically  scheduled  and 
recorded  when  complete 

-  CM  record  ensures  that  a  history  is  established  for  the  piece  of 
ground  equipment  that  requires  to  be  maintained. 

d)  Calibration  control  Program: 

-  It  ensures  that  all  Test,  Measurement  and  Diagnostic  Equipment 
(TMDE)  is  calibrated  within  certain  range  of  scale. 

e)  Tool  Control: 

-  Ensures  accountability  of  all  tools  in  stand-alone  sets,  chests  or  kits 
and  or  if  they  belong  to  a  PEI. 

f)  Product  Quality  Deficiency  Report  (PQDR): 

Provides  information  to  activities  responsible  for  development, 
procurement,  or  management  of  equipment  concerning  deficiencies 
in  material,  design,  or  procurement 

-  It  enables  the  activities  to  initiate  action  to  correct  the  reported 
deficiency. 

g)  Modification  Control:  This  program  gives  the  equipment  owner  the  means  of 
accurately  determining  the  modification  status  on  assigned  equipment.  There  are 
two  types  of  modification:  Urgent  and  Normal. 

-  Normal:  modification  lend  themselves  to  acceptance  scheduling 
usually  within  one  year 

Urgent:  modification  require  that  the  equipment  be  dead  lined  or 
sharply  curtailed  until  the  modification  is  applied. 
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h)  Publication  Libraries:  The  publications  fall  into  two  categories: 

-  Technical  (Marine  Corps  Orders,  Bulletins,  etc.) 

-  Non-technical  (Technical  Manuals,  Stock  Listings,  Modification 
Instructions,  etc.). 

II.  Support  Supply: 

Within  the  support  supply,  there  are  six  sub  functional  areas.  They  are  as  follows: 

-  Pre-expended  Bins 

-  ERO  parts  usage 

-  Repair  parts  usage 

-  New  equipment 

-  Maintenance  and  supply  validation 
Maintenance  and  supply  reconciliation 

a)  Pre-expended  Bin  (PEB): 

-  For  mechanics  and  technicians  performing  quick  repairs  within  the 
maintenance  facility,  it  provides  continuous  availability  of  low-cost, 
fast  moving  items. 

b)  ERO  Parts  Bin: 

-  It  is  an  area  secure  against  pilferage  and  organizes  repair  parts 
waiting  to  be  installed  on  equipment  until  the  mechanic  or  technician 
requests  them  for  installation 

-  Repair  parts  held  in  the  bin  may  either  be  new  or  used  repair  parts 
and  all  repair  parts  must  be  signed  for  upon  removal  from  the  repair 
part  bin. 

c)  Repair  parts  usage: 

-  All  repaired  parts  must  either  be  applied  to  a  piece  of  equipment  or 
‘rolled  back’  to  the  supply  system  for  another  unit  to  use 

-  The  aforementioned  is  based  on  receipts,  cancellations,  and  parts 
applied. 

d)  New  Equipment: 

-  All  new  equipment  will  have  a  fielding  plan  and  will  give  detailed 
instructions  on  placing  the  new  equipment  into  service 

-  Currently  User  Logistics  Support  Summary  (ULSS)  is  used  to 
accomplish  this. 

e)  Maintenance  and  Supply  Validation: 

MIMMS  Clerk  will  validate  the  existence  or  non-existence  of  all 
repairs,  repair  parts,  status  quo  and  conditions  of  equipment  and 
items  that  are  in  the  maintenance  cycle 

-  It  is  accomplished  using  Daily  Transaction  Listing  (DTL) 
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f)  Maintenance  and  Supply  Reconciliation: 

-  Not  only  the  validation  of  the  repair  parts  are  done  but  also  have  to 
reconcile  with  the  unit  supply  section  to  ensure  that  all  pending 
actions  between  supply  and  the  maintenance  section  are 
accomplished  or  not 

III.  MIMMS-AIS: 

Within  MIMMS-AIS,  there  are  two  sub  functional  areas  and  are  as  follows: 

-  MIMMS/  Marine  Corps  Ground  Equipment  Resources  Report 
(MCGERR) 

-  MIMMS  input  and  output  reports 

a)  MIMMS  and  Marine  Corps  Ground  Equipment  Resources  Report  (MCGERR): 

It  is  a  computer  oriented  command  information  system  designed  to 
provide  information  on  ground  equipment  readiness  of  Marine  Corps 
unit 

Readiness  relates  to  the  ability  of  a  certain  piece  of  equipment  (or 
unit)  to  accomplish  a  certain  task  which  is  specifically  designed  to 
achieve 

b)  Input  and  Output  of  MIMMS  and  MCGERR: 

Maintenance  Management  specialist  will  take  the  raw  data  and 
actually  keypunch  it  into  the  AIS  and  ensure  that  the  data  was 
properly  received  by  MISCO  (Maintenance  Information  System 
Coordination  Office) 

-  This  information  will  enable  to  ‘puli’  certain  type  of  information  out  of 
the  system  by  means  of  an  automated  retrieval  system 


IV.  MISCO: 

There  are  four  sub  functional  areas  and  are  as  follows: 

-  Monitor  the  operation  of  Ml  I M MS/M CG ERR 

-  Supporting  the  customer 

-  Resources 
Production 

a)  Monitor  the  operation  of  MIMMS/MCGERR: 

-  To  ensure  that  the  MIIMIMS  program  is  updated  with  all  the  current 
changes  that  are  received  from  the  Regional  Automated  Service 
Center  (RASC) 

-  Maintenance  Management  personal  uses  MIMMS  to  input  the  data 
into  the  automated  system  whereas,  the  supply  support  personnel 
use  the  Supported  Activities  Supply  Support  System  (SASSY)  and 
Asset  Tracking  Logistics  Automated  Support  System  (ATLASS)  to 
input  their  information  and  follow  on  with  the  requirements 

-  Both  these  systems  must  interface  on  a  systematic  basis  in  order  to 
‘feed’  each  other  with  updates. 
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b)  Supporting  the  customer: 

-  It  consists  of  activities  such  as,  answering  questions,  inputting  data, 
and  giving  guidance  in  the  MIMMS  field 

-  Maintenance  management  personnel  must  be  proficient  to  analyze 
the  data  and  make  recommendations  for  the  unit 

c)  Resources: 

Equipment  cannot  be  repaired  without  the  mechanic’s  time, 
equipment  time,  and  manager’s  time 

-  Basic  tools  that  are  used  to  repair  parts  are:  repair  parts,  tools  and 
publications 

-  Funding 

d)  Production: 

Maintenance  production  is  concerned  with  the  actual  repair  of 
equipment  that  includes  calibration,  modification,  corrective 
maintenance  (CM),  and  preventive  maintenance  (PM) 

-  It  also  considers  overhaul,  rebuild,  conversion,  and  modernization  of 
equipment. 

V.  Commodity  Sections: 

-  Common  commodities  that  are  found  in  the  battalion/squadron  are: 
Motor  transport,  Engineer,  communications,  and  ordnance. 
Commodity  managers,  supply  officer,  and  maintenance  management 
officer  (MMO)  are  special  staff  officers  who  fall  under  the  cognizance 
of  S-4 

-  The  maintenance  management  personnel  serve  as  a  liaisons 
between  supply/maintenance  commodity  shops  and  the  S-4  Officer 
to  ensure  rapid  maintenance  turn  around  and  accurate  readiness 
reporting 

VI.  Maintenance  Management  Standard  Operating  Procedures  (MMSOP): 

All  ground  units  are  required  to  have  a  set  procedure  to  follow  on  a  systematic 

basis  and  can  be  either  written  by  the  unit  or  use  higher  headquarters  MMSOP. 

The  following  are  the  two  procedures: 

-  Desktop  Procedures  (DTP):  Frequent  change  of  personnel  within  the 
units  result  in  a  lack  of  expertise  and  will  interrupt  the  day-to-day 
operations.  DTP  assists  and  improve  the  overall  efficiency  of  an 
organization. 

-  Turnover  Folders  (TOF):  They  are  like  the  DTP  but  goes  into  greater 
detail  for  the  maintenance  manager. 
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3.4  Concept  of  Autonomic  Logistics  (AL)  on  LAV 

3.4.1  Focus  LAV  from  JSF  perspective 

Our  study  will  focus  on  how  maintenance  (using  prognosis  and  diagnosis) 
information  from  a  principal  end  item  (PEI),  such  as  a  Light  Armored  Vehicle  (LAV) 
is  distributed  to  the  concerned  personnel  for  replenishment.  With  this  notion  as  our 
basis,  the  scope  of  our  project  will  consider  the  AL  concept  to  be  the  end-to-end 
information  distribution  flow. 

We  have  used  some  of  the  basic  foundations  of  JSF  in  building  the  focus  for  LAV 
overall  AL  [Appendix:  3],  The  four  significant  features  of  the  AL  concept  to  provide 
a  futuristic  logistics  support  for  the  platform  LAV  are  as  follows: 

1.  Preventive  Maintenance  and  Health  Monitoring 

2.  Shared  Data  Environment  (SHADE) 

3.  Technologically  Enabled  Maintainer 

4.  Operational  Architecture  for  Advanced  Logistics  Infrastructure 
Preventive  and  Health  Management: 


Sensors  placed  on  the  critical  parts  in  a  LAV  transmit  status  data  to  a  unit  personal 
who/which  will  convert  this  data  into  information  for  a  specific  subsystem.  The  unit 
personal  might  be  a  software  module,  monitoring  system  and/or  man-in-the-loop, 
which  fuse  the  information  obtained  from  various  sources  by  means  of  data  fusion, 
reasoning,  and  anomalies.  This  information  will  determine  whether  the  part  or 
component  of  a  specific  subsystem  exhibit  certain  characteristic  that  may  lead  to 
part  failure. 

Information  collected  by  the  unit  personal  will  then  be  transmitted  to  a  unit 
commander  for  further  information  fusion  and  to  eliminate  ambiguities.  Data  fusion 
will  enable  the  system  to  avoid  false  alarms  by  cross  checking  the  anomalies  with 
information  obtained  from  other  subsystems. 

The  unit  commander  filters  information  and  sends  certain  information  to  the  LAV 
operator  and  the  remaining  information  to  the  maintenance  personnel  for  action. 
Data  fusion  will  enable  the  system  to  avoid  false  alarms  by  cross  checking  the 
anomalies  with  information  obtained  from  other  subsystems.  Sensor  information 
will  be  validated  at  the  unit  personal  and  commander  level. 

Other  aspect  will  be  the  prognostic  calculation,  which  will  aid  in  calculating  the 
remaining  useful  life  of  a  specific  component  in  a  subsystem.  This  information 
together  with  the  rest  of  the  information  from  the  unit  commander  is  transmitted  to 
SHADE,  which  will  trigger  or  inform  the  logistics  supply  what  it  has  to  do  to 
maintain  the  LAV  fully  operational. 
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In  other  words,  prognosis  in  a  LAV  will  estimate  the  remaining  useful  life  of  a 
component  and  allow  a  lead-time  for  the  logistics  pipeline  to  get  parts  and  to 
educate  the  maintainer  to  change  the  respective  parts. 

Shared  Data  Environment  (SHADE): 

The  significant  element  of  AL  will  be  the  SHADE.  It  will  serve  as  an  interface  that 
would  take  the  information  from  the  unit  commander  and  transmit  to  all  the  other 
necessary  maintenance  management,  logistics,  supply,  mission  planning  etc. 
Some  tasks  that  will  be  performed  either  automatically  or  integrated  with  SHADE 
are  as  follows: 

-  Mission  planning 

Maintenance  action  scheduling  and  training 

-  Ordering  of  spare  parts 

Storing  maintenance,  training,  spare  parts,  and  logistic  information  in  the 
database  warehouse 

The  aforementioned  automated  tasks  will  include  a  man-in-the-loop  with  certain 
authority  to  access  the  system  and  make  necessary  changes. 

In  other  words,  the  information  from  the  prognostics  and  health  management 
system  will  allow  the  SHADE  to  trigger  relevant  actions  and  recommendations. 

Technologically  Enabled  Maintainer: 

Maintainer  in  the  AL  concept  will  have  a  sound  knowledge  in  modern  and 
technologically  capable  tools  to  act  efficiently  when  called  for  immediate 
maintenance.  The  tools  include:  comprehensive  knowledge  of  the  platform  before 
the  maintainer  begins  work,  real  time  guidance  to  provide  supplementary 
information  when  required,  and  timings  to  conduct  the  specific  task. 

Advanced  Logistics  Infrastructure: 

If  the  logistics  infrastructure  does  not  provide  the  right  part  at  the  right  time  at  the 
right  place  then  the  above  mentioned  two  systems  would  be  of  no  avail.  To  have 
an  adaptive  Logistics  infrastructure,  the  MC  logistics  enterprise  is  currently 
working  on  with  the  Operational  Architecture  [Appendix  1],  This  architecture 
captures  the  information  flow  between  supported  unit,  supporting  unit  and  the 
enterprise  level. 

In  brief,  the  information  from  Preventive  and  Health  Management  system  will 
trigger  the  advanced  logistics  infrastructure  through  SHADE  and  will  assign  the 
maintainer  to  fulfill  the  maintenance  action  so  that  the  LAV  platform  is  fully 
operational  during  its  mission.  The  LAV  AL  will  be  enabled  with  both  the  COTS 
and  GOTS  software.  We  show  in  Figure  3.6  our  conceptual  view  of  LAV  AL. 
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Figure  3.6:  Conceptual  view  of  LAV  AL 
3.4.2  Work  Break  down  Structure  (WBS)  for  LAV  -  25 

In  order  to  have  a  fully  functional  Preventive  and  Health  Monitoring  system  in  a 
LAV,  we  first  have  to  study  the  LAV  features  and  analyze  its  critical  parts.  After 
identifying  the  critical  parts,  different  types  of  sensors  will  be  placed  on  it  to  collect 
prognosis/diagnosis  data  from  the  platform. 

To  achieve  the  above  goal,  we  have  to  thoroughly  understand  the  WBS  of  a  LAV. 
With  the  information  obtained  from  Maj.  Landry,  we  came  up  with  a  first  cut  WBS 
as  shown  in  Figure  3.7. 

Our  present  work  is  focused  on  extracting  relevant  part  information  by  analysis 
[Refer  Chapter  No.  6]  from  the  Quad  Model  data  set  sent  by  Maj.  Landry.  This 
information  will  later  be  linked  to  WBS,  which  will  hence  outline  the  next  level  or 
subsystem  for  the  WBS. 
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Figure  3.7:  WBS  for  LAV  25 
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4  Maintenance  Activities 

In  an  attempt  to  answer  some  of  the  questions  posed  in  previous  sections 
regarding  how  maintenance  data  can  be  generated  &  processed  autonomously 
and  further  distributed  for  triggering  specific  functions  within  the  logistics  chain,  the 
literature  related  to  Sensor  Processing,  Condition  Based  Maintenance  (CBM)  in 
the  Army,  Maintenance  in  Aviation  Industry,  Industrial  Logisitcs  Applications: 
Penske  Case,  Maintenance  and  Automotive  Telematics  -  GM  Onstar  Case  study 
were  reviewed.  Each  of  these  studies  revealed  varied  aspects  of  maintenance  that 
are  suggestive  of  solution  methodologies  for  the  integrated  diagnostics  of  ground 
equipment. 


4.1  Sensor  Processing 

In  the  process  of  applying  diagnostics  to  a  specific  subsystem  within  the  LAV  the 
characteristics  of  the  subsystems  have  to  be  analyzed  along  two  perspectives.  The 
first  being  the  criticality  of  the  sub-system,  this  questions  whether  or  not  to  use 
diagnostics  module  to  monitor  the  condition  of  a  specific  subsystem.  The  second 
perspective  questions  what  types  of  sensors  are  commercially  available  and  what 
sensor  processing  techniques  can  be  used  to  diagnose  the  selected  subsystem. 
Appendix:  4  serves  the  purpose  of  aggregating  information  about  commercially 
available  sensors  and  different  sensor  processing  techniques  that  are  potential 
candidates  for  application  to  CBM. 

The  sensors  are  grouped  as  mechanical  sensors,  electrical  sensors  and 
communication  sensors.  The  study  reviews  a  wide  spectrum  of  sensors  - 
transducers,  classical  integrated  sensors  and  smart  sensors.  The  signal 
processing  literature  entails  signal  conditioning  and  processing.  The  literature  also 
gives  a  high  level  description  of  the  methodology  by  which  the  sensors  can  be 
used  for  diagnostics  within  an  LAV.  It  further  describes  the  different  analysis 
techniques  that  can  be  used  to  make  relevant  inference  regarding  the  condition  of 
the  subsystem  from  the  corresponding  signal  data. 


4.2  Condition  Based  Maintenance  (CBM)  in  the  Army 

CBM  is  defined  as  a  set  of  actions  taken  as  a  consequence  of  knowing  the  current 
operating  status  of  the  equipment.  These  would  include  maintenance  scheduling, 
sourcing  parts  for  replacement  and  making  orders  for  replenishment  to  maintain  a 
certain  level  of  inventory.  Determining  current  equipment  operating  status  can  be 
accomplished  in  three  basic  ways: 

□  By  using  sensors  and  computers  that  are  embedded  into  the  operating 
equipment  and  monitored  on-the-fly, 
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□  By  applying  portable  sensing  equipment  that  tie  up  to  an  interface  or  wiring 
harness  to  “read”  embedded  sensors,  or  to  apply  the  sensor  itself,  such  as  a 
stand-alone  wear  measurement, 

□  By  using  manual  gauges  or  instruments,  such  as  a  tire-wear  gauge 

The  intent  of  CBM  is  to  perform  maintenance  only  when  there  is  objective  evidence 
of  need.  The  technical  capability  of  CBM  is  to  identify  current  equipment  conditions. 
Acting  upon  these  condition  indicators  is  more  than  a  matter  of  being  able  to 
schedule  maintenance  or  forecast  failure.  Once  the  objective  evidence  of  need  is 
in  hand,  forecasting  or  scheduling  maintenance  tasks  can  be  performed.  The  army 
is  currently  working  on  CBM  programs  within  three  specific  time  frames.  In  the 
short  term,  the  focus  is  on  immediate  technology  insertion  to  enhance  diagnostics. 
In  the  near  future,  the  goal  is  to  develop  anticipatory  maintenance  capabilities 
within  the  ground  equipment  and  in  the  long  run,  it  aims  to  develop  a  proof  of 
concept  for  embedded  diagnostics  for  a  common  architecture  and  approach.  The 
review  conducted  on  the  ongoing  CBM  projects  within  the  army  reveals  the  wide 
variety  of  sensors  that  are  used  for  condition  monitoring.  The  conceptual  ideas  of 
the  rule  based  systems  that  facilitate  transformation  of  the  sensor  or  model  data 
into  meaningful  inference  have  been  captured  within  the  literature.  The  overarching 
concept  of  autonomic  logistics  that  has  been  the  guiding  framework  for  equipment 
maintenance  within  the  army  can  be  imbibed  and  tailored  to  suit  the  maintenance 
processes  for  ground  equipment  within  the  USMC.  A  detailed  description  of 
ongoing  CBM  programs  within  the  army  is  provided  in  Appendix  5. 


4.3  Maintenance  in  Aviation  Industry 

An  important  task  is  to  identify  the  critical  components  within  the  LAV  that  would 
prove  ideal  candidates  for  diagnostics.  In  the  aviation  industry,  maintainability  of 
the  machinery  is  a  key  factor  and  is  considered  right  from  the  design  stage.  The 
criticality  of  the  machinery  within  the  commercial  aircrafts  have  been  identified  and 
condition  based  monitoring  is  being  used  so  as  to  conduct  diagnostics  while  the 
aircraft  is  in  use.  This  enables  the  maintenance  action  to  be  taken  on  time  and 
prevent  failures.  The  technology  used  for  monitoring  aircraft  engines  has  greatly 
improved  over  the  years  with  the  use  of  high  fidelity  sensors.  The  main 
breakthrough  in  this  field  is  the  development  of  a  central  maintenance  computer 
that  acquires  and  processes  data  from  an  entire  fleet  of  aircrafts  when  they  are  in 
use.  The  on-board  processing  unit  interprets  the  signal  data  and  transmits  the 
coded  information  to  the  central  maintenance  computer  via  satellite  based  aircraft 
communication  and  addressing  system  (ACARS).  This  data  is  then  distributed  to 
other  bases  if  needed.  A  web-based  portal  provides  real  time  information  regarding 
the  status  of  all  the  aircrafts  within  the  fleet.  Thus,  the  decision  makers  can  find  the 
needed  information  any  time  -  anywhere.  Logic  diagrams  have  been  generated  for 
performing  maintenance  activities.  The  schema  provides  a  sequential  set  of 
directions  for  accomplishing  the  maintenance  task  by  following  the  logic  diagram. 
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For  detailed  information  on  Aviation  Industry  Maintenance  (Boeing),  refer 
Appendix:  6. 


4.4  Industrial  Logistics  Applications:  Penske  case 

Penske,  one  the  country’s  largest  logistics  companies,  has  a  large  fleet  of  vehicles. 
The  maintenance  processes  practiced  within  the  organization  reflect  some  of  the 
best  practices  within  the  commercial  sector.  Reviewing  this  information  could  prove 
as  a  good  reference  for  maintenance  process  improvement  within  the  USMC.  The 
essence  of  the  maintenance  process  followed  ate  Penske  includes  capturing  the 
performance  data  of  specific  systems  such  as  engines,  fluids,  parts,  tires  etc. 
Every  maintenance  transaction  on  each  vehicle  is  also  captured.  This  data  forms 
the  basis  for  analysis  and  indicates  the  defect  levels  of  the  systems.  The  current 
equipment  status  is  translated  into  corrective  feedback  and  distributed  to  Penske 
technicians  as  well  as  designers  for  the  next  generation  vehicles.  A  brief 
description  of  the  joint  studies  done  by  Penske  partnering  with  Ford,  Mission 
Foods  and  Whirlpool  are  included  in  the  Appendix:  7. 


4.5  Maintenance  and  Automotive  Telematics  -  GM  Onstar  Case 
study 

A  critical  review  of  the  telematics  literature  presents  the  use  of  condition  monitoring 
within  an  automobile.  The  emphasis  in  the  literature  is  on  available  technologies 
for  communication  and  location  based  services,  it  does  not  explore  in  depth  the 
sensor  based  techniques  for  diagnostics  but  helps  comprehend  in  a  generic 
fashion  the  data  acquisition  and  communication  process.  The  telematics  enabled 
vehicle  essentially  is  capable  of  two-way  communication,  location  identification  and 
has  a  control  unit  that  is  interfaced  with  the  vehicle’s  electronic  systems. 

The  telematics  control  unit  is  an  embedded  computer  designed  for  telematics 
functions.  The  user  interface  uses  audio  capabilities  within  the  auto  and  has  a 
display  unit  as  well.  The  control  unit  essentially  has  limited  capabilities  and  is 
supported  by  a  remote  server.  This  reduces  manufacturing  costs  as  well  as 
minimizes  technology  obsolescence.  The  human  machine  interface  exploits  the 
audio  capabilities  available  within  the  vehicle.  Speech  recognition  systems  are 
currently  used  in  automobiles  for  the  command  input.  Large  display  units  could 
prove  a  major  distraction  to  the  driver  and  so  text-to-speech  output  via  the  audio  is 
the  current  state-of-the-art.  Emerging  technologies  in  the  areas  of  software 
platforms  that  are  more  flexible  and  communication  technologies  which  use  cellular 
and  satellite  networking  will  greatly  enhance  the  performance  of  telematics 
systems.  High  bandwidth  Wireless  local  area  networks  co-existing  with  blue  tooth 
technologies  will  facilitate  the  automobiles  to  communicate  with  each  other  and 
other  local  systems  and  thus  increase  the  support  available  to  the  vehicles. 
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Though  the  operating  conditions  vary  vastly  in  a  combat  environment  the 
technologies  that  are  currently  being  used  and  have  been  identified  as  the  future 
enhancers  for  automotive  telematics,  are  relevant  to  the  IDGE  study.  The 
conceptual  description  of  the  telematics  techniques  and  the  case  study  on  GM 
Onstar  detailed  in  the  Appendix:  8  could  provide  the  right  direction  towards 
realizing  a  framework  for  integrated  diagnostics  of  the  ground  equipment.  It  also 
helps  identify  the  current  state-of-the-art  technologies  in  remote  diagnostics  and 
the  future  technologies  that  could  enhance  the  same. 
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5  Use  Cases  as  a  Mechanism  for  Envisioning  the  IDGE 
System 

5.1  What  Are  Use  Cases? 

Use  Cases  are  a  technique  that  allows  modeling  what  an  envisioned  system  will  do. 
With  use  cases,  the  analysis  can  be  performed  at  a  level  that  is  easily  accessible 
to  the  potential  users.  It  also  allows  the  system  architects  and  future  designers  the 
opportunity  to  scope  the  project  and  gives  the  project  some  structure.  A  Use  Case, 
thus,  represents  a  unit  of  analysis  that  can  progress  to  becoming  a  unit  of  effort 
estimation,  and  the  smallest  unit  of  delivery,  testing  and  deployment.  An  important 
ancillary  benefit  of  use  cases,  therefore,  is  that  they  can  be  developed  in  an 
iterative  and  incremental  manner  for  eliciting  requirements,  developing, 
implementing  and  deployment.  As  a  user-centered  analysis  technique,  the  purpose 
of  a  use  case  is  to  capture  a  scenario  that  would  yield  a  result  of  measurable  value 
to  an  actor.  A  use  case  may  involve  multiple  actors,  but  only  a  single  actor  initiates 
the  use  case.  Because  actors  are  beyond  the  scope  of  the  system,  use-case 
modeling  ignores  direct  interactions  between  actors. 

The  term  use  case  was  introduced  by  Ivar  Jacobson  et  al.  [14].  A  use  case  is  a 
description  of  a  cohesive  set  of  possible  interactions  that  an  individual  actor  will 
carry  out  with  a  system.  An  actor  is  a  role  played  by  a  user  (i.e.,  an  external  entity 
that  interacts  directly  with  the  system).  A  use  case  is  thus  a  general  way  of  using 
some  part  of  the  functionality  of  a  system. 


Figure  5.1:  Primary  Use  Case  Notations 

A  use  case  defines  a  goal-oriented  set  of  interactions  between  external  actors  and 
the  system  under  consideration.  Actors  are  parties  outside  the  system  that  interact 
with  the  system.  An  actor  may  be  a  class  of  users,  roles  users  can  play,  or  other 
systems.  The  system  is  treated  as  a  "black  box",  and  the  interactions  with  system, 
including  system  responses,  are  as  perceived  from  outside  the  system.  Thus,  use 
cases  capture  who  (actor)  does  what  (interaction)  with  the  system,  for  what 
purpose  (goal),  without  dealing  with  system  internals.  A  complete  set  of  use  cases 
specifies  all  the  different  ways  to  use  the  system,  and  therefore  defines  all 
behavior  required  of  the  system,  bounding  the  scope  of  the  system. 
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A  use  case  is,  thus,  not  a  single  instance  of  a  scenario  but  rather  a  ‘class’  that 
specifies  a  set  of  related  usage  scenarios,  each  of  which  captures  a  specific 
course  of  interactions  that  take  place  between  one  or  more  actors  and  the  system. 
The  description  of  an  individual  use  case  typically  can  be  divided  into  a  basic 
course  and  zero  or  more  alternative  courses.  The  basic  course  of  a  use  case  is  the 
most  common  or  important  sequence  of  transactions  that  satisfy  the  use  case.  The 
basic  course  is  therefore  always  developed  first.  The  alternative  courses  are 
variants  of  the  basic  course  and  are  often  used  to  identify  error  handling.  Within 
reason,  the  more  alternative  courses  identified  and  described,  the  more  complete 
the  description  of  the  use  case  and  the  more  robust  the  resulting  system. 

Use  Cases  are  not  a  functional  decomposition  model.  They  do  not  capture  how  the 
system  will  do  something.  That  is  the  domain  of  developers.  They  do  provide  a 
vehicle  for  communicating  with  the  developers  by  identifying  scenarios  of  value  to 
the  users,  and  provide  a  tool  for  envisioning  and  architecting  that  can  be  used  to 
communicate  with  both,  the  system  developers  and  system  users.  Keeping  these 
objectives  in  mind,  generally,  use  case  steps  are  written  in  an  easy-to-understand 
structured  narrative  using  the  vocabulary  of  the  domain.  This  is  engaging  for  users 
who  can  easily  follow  and  validate  the  use  cases,  and  the  accessibility  encourages 
users  to  be  actively  involved  in  defining  the  requirements.  The  set  of  all  use  case 
descriptions,  thus,  specifies  the  complete  functionality  of  the  system. 


5.2  Why  and  How  Use  Cases  can  be  used  to  Envision  IDGE? 

For  an  open-ended  problem  such  as  the  proposed  IDGE  initiative,  use  cases 
represent  an  indispensable  tool  precisely  because  of  its  vague,  ill-structured, 
futuristic  focus.  The  myriad  of  actors  involved  in  the  system  need  to  make  their 
perspectives  clear.  The  research  team  needs  a  technique  that  they  can  use  to 
understand  and  envision  the  envisioned  IDGE  effort  in  terms  of  meaningful  chunks. 
These  requirements  make  use  cases  the  appropriate  choice  for  envisioning  IDGE. 
With  the  use  cases,  IDGE  also  inherits  a  rich  stream  of  research  and  a  strategy 
that  the  research  team  can  follow  to  track  progress,  and  integrate  various  elements. 
A  simple  statement  of  this  strategy  is  shown  below. 

1 .  Define  the  problem  informally  in  the  domain  of  interest 

2.  Develop  an  informal  strategy  for  the  domain  of  interest 

3.  Formalize  the  strategy  as  use  case  chunks 

4.  Use  the  use  cases  to  identify  information  of  interest 

5.  Clarify  specifications 

It  is  the  very  simplicity  of  use  cases  that  makes  them  so  powerful.  The  steps  can 
iterate  a  number  of  times  as  the  outcomes  of  each  inform  the  next  step  as  well  as 
the  overall  process.  The  steps  are  instantiated  for  the  IDGE  below. 

1 .  First,  the  problem  can  be  defined  informally  to  start  the  process.  In  the  case 
of  the  IDGE  system,  this  can  be  articulated  as  application  of  the  autonomic 
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logistics  concept  for  ground  equipment  to  ensure  better  maintenance  of 
ground  equipment. 

2.  Second,  an  informal  strategy  can  be  developed  for  the  domain  of  interest.  In 
case  of  IDGE,  this  involved  choosing  the  LAV  as  an  exemplar  to  make  the 
discussions  concrete,  and  scoping  the  discussion  by  the  OA  processes  (on 
the  top-side)  and  the  sensor  architectures  (on  the  bottom-side). 

3.  Third,  the  strategy  can  be  formalized  as  use  case  chunks.  Identification  of 
use  cases  thus  requires  chunking  the  functionality  of  the  envisioned  system 
into  cognitively  and  pragmatically  manageable  units.  For  the  IDGE,  this 
means  understanding  different  roles  (actors)  and  how  they  will  interact  with 
the  proposed  system  at  different  times  and  to  achieve  different  goals. 

4.  Fourth,  the  use  cases  can  be  used  in  a  manner  that  directly  addresses 
concerns  of  interest.  For  the  IDGE,  the  immediate  concerns  of  interest  are 
the  data  implications  and  the  universal  data  requirements.  These  can  be 
tagged  to  the  use  case  descriptions  to  identify  the  data  implications  of  each 
use  case. 

5.  Finally,  the  specifications  can  be  formalized  to  the  extent  possible  so  the 
process  can  repeat. 

An  example  set  of  use  cases  [15]  clarifies  how  use  cases  may  be  written  in  the  first 
pass  through  this  strategy.  The  envisioned  use  cases  for  Door  Master,  a  security 
system  for  controlling  entry  of  employees  through  a  secured  door  can  be  captured 
by  use  cases  that  include  the  following. 

a.  Enter  the  Disabled  Door.  Employees  and  security  guards  enter  freely 
through  the  door  when  Door  Master  is  disabled. 

b.  Enter  the  Secured  Door.  Employees  and  security  guards  enter  through  the 
door  by  entering  the  entry  code  on  the  numeric  keypad,  entering  through  the 
door,  and  closing  the  door  behind  them. 

c.  Change  the  Entry  Code.  Security  guards  change  the  entry  code  by  pressing 
the  change  entry  code  button  on  the  control  panel,  providing  authorization 
by  entering  the  security  code  on  the  numeric  keypad,  entering  the  new  entry 
code  on  the  numeric  keypad,  and  verifying  the  new  entry  code  by  reentering 
it  on  the  numeric  keypad. 

d.  Change  the  Security  Code.  Security  guards  change  the  security  code  by 
pressing  the  change  security  code  button  on  the  control  panel,  providing 
authorization  by  entering  the  old  security  code  on  the  numeric  keypad, 
entering  the  new  security  code  on  the  numeric  keypad,  and  verifying  the 
new  security  code  by  reentering  it  on  the  numeric  keypad. 

e.  Enable  the  Door  Master.  Security  guards  enable  Door  Master  by  pressing 
the  enable  button  on  the  control  panel  and  providing  authorization  by 
entering  the  security  code  on  the  numeric  keypad.  Door  master  then  turns 
off  the  disabled  light,  turns  on  the  enabled  light,  and  locks  the  door. 
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f.  Disable  the  Door  Master.  Security  guards  disable  Door  Master  by  pressing 
the  disable  button  on  the  control  panel  and  providing  authorization  by 
entering  the  security  code  on  the  numeric  keypad.  Door  master  then  turns 
off  the  enabled  light,  turns  on  the  disabled  light,  and  unlocks  the  door. 

g.  Enter  the  Entry  Code.  Employees  and  security  guards  enter  the  entry  code 
by  pressing  five  keys  on  the  numeric  keypad  followed  by  the  enter  key.  Door 
master  beeps  after  each  key  and  verifies  the  entry  code. 

h.  Enter  the  Security  Code.  Employees  and  security  guards  enter  the  entry 
code  by  pressing  seven  keys  on  the  numeric  keypad  followed  by  the  enter 
key.  Door  master  beeps  after  each  key  and  verifies  the  entry  code. 

i.  Raise  the  Alarm.  The  alarm  is  raised  if  the  door  is  left  open  too  long  or  if  the 
door  is  not  shut  when  Door  Master  is  enabled.  The  security  guards  disable 
the  alarm  by  entering  the  security  code. 
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6  Data  Mining  for  Maintenance  Design  and  Analysis 

6.1  Introduction 

The  quadrant  model  is  a  classification  tool  that  can  be  used  to  classify  the 
elements  along  two  distinctly  different  attributes.  Relevant  to  this  study  these 
attributes  are  mission  value  and  risk/uniqueness.  The  main  computation  that  has  to 
be  performed  is  to  quantify  risk  and  mission  value  associated  with  the  different 
components.  The  generic  quadrant  model  that  can  be  used  has  the  X-axis 
representing  the  mission  value  of  a  particular  component  and  the  Y-axis 
representing  the  risk/uniqueness  associated  with  the  components.  The  value 
increases  from  low  to  high  as  we  traverse  from  left  to  right  along  the  X-axis  and  the 
risk  increases  from  low  to  high  as  we  traverse  bottom  up  along  the  Y-axis.  This 
method  of  classification  would  essentially  help  identify  the  critical  components 
within  the  structure  of  the  LAV.  Once  this  is  achieved,  the  critical  component  can 
be  used  as  an  ideal  case  study  for  using  condition  based  maintenance  and  further 
developing  the  information  flows  that  can  be  autonomously  aggregated  to  form  the 
inputs  to  the  ERP  system. 

Historical  data,  such  as  frequency  of  failures,  mean  time  between  failures,  repair 
cost,  inventory  levels,  fill  rate  and  other  data  inputs  can  be  used  for  mining  and 
identifying  patterns  which  will  form  important  inputs  to  the  decision  support 
systems  -  for  the  tactical,  operational  and  strategic  level.  The  first  step  towards 
achieving  this  goal  would  be  to  acquire  as  much  historical  data  as  available  within 
the  operational  units  of  the  USMC. 

•  Qualitative  attributes  have  to  be  translated  to  computable  quantities. 

•  Attributes  - 

-  Risk  involved  in  acquiring  the  component  for  replacement. 

-  Value  of  the  component  to  the  accomplishment  of  the  mission. 

The  quadrant  model  has  two  ‘dividers’  that  partition  the  diagram  into  four  distinct 
quadrants.  They  are  categorized  as  Routine,  Leveraged,  Bottleneck  and  Critical. 
Each  of  the  quadrants  represents  components  with  distinct  levels  of  risk  and 
mission  value.  The  dividers  can  be  adjusted  to  change  the  fraction  of  components 
falling  into  the  four  categories.  The  diagram  given  below  gives  the  quadrant  model 
with  a  sample  of  the  attributes  that  ascertain  the  belonging  of  the  components  to 
the  respective  quadrants. 
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Figure  6.1 :  Quadrant  model  showing  the  attributes  &  a  sample  of  the  various 
criteria  that  determine  the  belonging  of  each  component  to  the  respective 

quadrants. 


6.1.1  Available  information 

The  data  that  is  currently  available  for  preliminary  analysis  has  been  obtained  from 
historical  data.  Some  of  the  attributes  that  have  been  specified  within  the  quadrant 
model  data  for  SECREPS  use  acronyms.  The  team  has  posted  questions 
regarding  these  acronyms  and  the  type  of  simulation  models  that  have  been  used 
in  the  data  analysis.  Though  the  current  understanding  of  the  data  worksheet 
made  available  by  the  USMC  is  limited,  the  worksheets  have  been  used  to 
categorize  the  different  components  into  the  different  quadrants  as  a  first  cut  to  the 
analysis.  The  data  specified  below  have  been  used  for  the  analysis. 

-  Data  on  108  subsystems  identified  by  the  National  Stock  number  and  the  NUNS 

-  The  repair  costs  associated  with  each  of  these  subsystems. 

-  The  unit  price  for  the  different  components. 

-  Demand  for  the  components  simulated  using  historical  data. 

-  Number  of  items  of  each  type  that  are  stocked. 

Using  this  information,  the  following  criteria  that  will  aptly  describe  the  risk  and 
mission  value  associated  with  the  components  were  identified. 

-  Difference  in  demand  and  number  of  components  stocked  (deficit). 

-  Cost  incurred  as  a  share  of  the  total  budget. 

-  The  ratio  of  the  repair  cost  to  the  component  cost. 

-  The  ratio  of  demand  for  a  component  to  the  total  demand  for  components. 

-  Ratio  of  the  demand  for  a  particular  component  to  the  number  stocked. 
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-  Frequency  of  breakdown  (1999-2001 ) 

The  idea  of  criticality  or  risk  associated  with  a  particular  component  is  determined 
by  the  perspective  or  view  along  which  the  analysis  is  carried  out.  For  instance  the 
same  component  would  prove  very  critical  to  the  finance  management  owing  to  the 
high  cost  of  repair  or  replacement,  while  it  may  not  be  equally  critical  to 
maintenance  management  owing  to  its  very  low  frequency  of  failure.  Thus  the  goal 
of  effectively  classifying  the  components  demands  using  various  perspectives  and 
working  on  the  relevant  criteria  for  classification.  The  criteria  for  classification  have 
to  be  understood  by  exploring  the  requirements  of  the  users  at  the  different  levels. 
This  information  has  to  be  generated  by  identifying  the  users  and  obtaining 
answers  to  specific  questions  through  interviews  and/or  questionnaires. 

An  example  illustrating  the  relevance  of  the  perspective  for  classification  is  given 
below  - 

Supply  perspective:  Viewing  the  information  from  a  supply  perspective  would 
reveal  that  the  main  criteria  that  have  to  be  considered  are  -  the  inventory  levels  of 
the  different  components,  customer  waiting  time,  demand  during  lead  time,  fill 
rates  etc. 

Monetary  perspective:  The  criteria  for  classification  while  reviewing  the  monetary 
implications  of  the  maintenance  of  different  components  would  be  as  follows  -  Unit 
cost  of  the  component,  Repair  costs,  Transportation  costs  and  overall  inventory 
costs  incurred  for  stocking  specific  amounts  of  each  component. 

Training  of  maintenance  personnel:  The  frequency  of  failures  would  play  an 
important  role  in  developing  relevant  maintenance  expertise  for  the  mechanics  who 
will  be  deployed  within  the  tactical  and  support  units.  It  is  logically  evident  that 
enabling  greater  number  of  mechanics,  through  appropriate  training,  to  perform 
maintenance  activities  on  frequently  failing  subsystems  will  improve  the  efficiency 
of  operations. 

Maintenance  support  systems  design:  The  necessity  of  a  system  offering  remote 
maintenance  support  to  the  mechanic  performing  maintenance  on  a  particular 
component  will  require  large  volumes  of  data  to  be  stored  and  transmitted  in  real¬ 
time.  Owing  to  the  limitations  in  communication  infrastructure  it  is  important  to 
choose  those  subsystems  to  which  such  a  support  is  critical.  This  can  again  be 
achieved  by  classifying  the  components  based  on  the  time  required  for 
maintenance  operation,  ease  of  problem  identification  and  localization. 

The  above  perspectives  are  just  a  representative  collection  of  the  different 
perspectives  along  which  the  components  can  be  classified.  The  list  is  definitely 
not  exhaustive  and  many  more  views  will  be  added  after  ascertaining  the 
requirements  of  the  users  who  would  be  interacting  with  the  information  system. 
The  final  goal  of  using  the  quadrant  model  to  develop  a  robust  classification 
schema  for  varied  uses  has  been  initiated  through  this  analysis. 


46 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  1 


6.2  DATA  ANALYSIS 

6.3  Quadrant  Model  for  the  LAV-25  (E0947)  SECREPS 

The  quadrant  model  used  by  the  USMC  categorizes  (classify)  the  LAV-25 
SECREPS  (Secondary  Repairables)  inventories  so  that  the  effectiveness  of 
procurement/contracting,  acquisition  logistics,  and  material  management  can  be 
improved.  From  the  analysis  of  sample  data  of  their  practice  study  (E0947 
SECREPS  Quad  Acq.xls),  it  is  found  that  variable  mission  value  and 
risk/uniqueness  related  information  for  the  each  LAV-25  SECREPS  part  are 
considered  to  build  two-by-two  matrix  with  4  different  cells,  namely  Bottleneck, 
Routine,  Leveraged,  and  Critical.  After  building  the  matrix,  the  4  cells  are  divided 
with  two  dividers,  one  is  the  divider  for  the  mission  value  (X-divider),  the  other  is 
the  divider  for  the  risk  /  uniqueness  (Y-divider).  From  the  current  analysis,  it  is 
found  that  the  decision  making  for  these  two  dividers  is  dependent  on  their  budget 
constraint.  Figure  6.2  shows  the  LAV-25  SECREPS  quadrant  model. 
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Figure  6.2:  LAV-25  SECREPS  Quadrant  Model 


6.4  ABC  Analysis  for  the  LAV-25  (E0947)  SECREPS 

ABC  analysis,  sometimes  referred  as  Pareto  analysis,  is  a  method  of  classifying 
items,  events,  or  activities  according  to  their  relative  importance.  It  is  frequently 
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used  in  inventory  management  where  it  is  used  to  classify  items  into  groups  based 
on  the  total  annual  expenditure  of  each  item. 

For  the  maintenance  of  the  LAV,  organizations  should  concentrate  on  the  high 
value  and  important  SECREPS  (Secondary  Repairables)  for  the  LAV. 


6.5  Study  of  ABC  Analysis  for  the  LAV-25  (E0947)  SECREPS 

First  Step:  Identify  criteria,  which  make  a  significant  level  of  control  important  for 
any  SECREP  part.  In  this  analysis,  since  most  of  data  fields  in  ‘E0947  SECREPS 
Quad  Acq.xls’  are  not  clearly  defined  at  this  moment,  two  possible  factors  for  this 
analysis  can  be  the  ‘average  annual  demand’  and  ‘cost’  for  each  repairable  part. 


NIIN 

Nomenclature 

Annual 

Demand 

Unit  Rcost 

Annual 

Requirement 

Value  (ARV) 

Cmul_ARV 

14304339 

SENSOR  UNIT.LASER  DETECTING 

7.40 

60654.10 

449107.93 

449107.93 

14427645 

ENGINE, DIESEL 

7.40 

28205.69 

208846.54 

657954.47 

11516429 

CONTROL  DISPLAY  UNIT 

29.23 

4602.12 

134510.57 

792465.04 

219063912 

DIFFERENTIAL, DRIVING  AXLE 

18.32 

6218.00 

113889.96 

906355.00 

11642599 

DISTRIBUTION  BOX 

7.79 

11508.66 

89699.88 

996054.88 

11660375 

HAND  STATION  ASSEMB 

6.24 

13933.55 

86879.79 

1082934.67 

+ 

+ 

Table  6.1 :  Annual  Requirement  Value  Table 

Second  Step:  These  two  factors  can  be  multiplied  to  give  the  annual  requirement 
value  (ARV)  -  the  total  value  of  annual  usage.  If  the  items  are  then  listed  in 
descending  order  of  ARV,  shown  at  above  table,  the  most  important  repairable 
parts  will  appear  at  the  top  of  the  list.  If  the  cumulative  ARV  is  then  plotted  against 
the  SECREPS  parts  then  a  Pareto  curve  will  be  obtained.  This  ABC  analysis  graph 
is  shown  in  the  next  figure. 
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Percent  ABC  Analysis  Chart 


Figure  6.3:  ABC  Analysis  Graph 


Class 

nun 

Nomenclature 

PercentARV 

Note 

A 

14304339 

SENSOR  UNIT, LASER  DETECTING 
SET 

24.95 

-  Careful 
physical 
control 

-  Very  reliable 
supplier 

-  Frequent, 
small  orders 

14427645 

ENGINE, DIESEL 

11.60 

11516429 

CONTROL  DISPLAY  UNIT 

7.47 

4 

i  (total  12  parts) 

i 

B 

10692638 

RECEIVER-TRANSMITTER, RADIO 

1.44 

-  Moderate 
control 

11954844 

AMPLIFIER, RADIO  FREQUENCY 

1.37 

11516431 

TRAVERSE  DRIVE 

1.10 

i 

+ 

i  (total  30  parts) 

C 

219083069 

STRUT  ASSEMBLY, VEHICULAR 
SUSPENS 

0.26 

-  Simple 
control  rules 
♦  Larger, 
infrequent 
orders 

14582495 

CABLE 

ASSEMBLY.POWER,  ELECTRICAL, 

0.25 

11643377 

CYLINDER  ASSEMBLY, HYDRAULIC 
BRAK 

0.25 

i  (total  61  parts) 

Table  6.2:  ABC  Analysis  Table 

In  this  case  study,  the  first  12%  of  repairable  parts  in  the  list,  class  A,  will  account 
for  approximately  75%  of  cumulative  ARV.  These  items  require  careful  physical 
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control  and  very  reliable  suppliers.  The  next,  30%  of  repairable  parts,  class  B,  will 
account  for  a  further  20%  of  cumulative  ARV,  and  the  last  58%  of  repairable  parts, 
class  C,  will  account  for  a  last  5%  of  cumulative  ARV.  These  results  are  shown  in 
the  above  table. 


6.6  Data  Mining  Methods  for  the  Classification  of  LAV-25 
(E0947)  SECREPS 

With  the  statistical  learning  approaches,  play  as  key  roles  in  Data  Mining,  the  input 
space  can  be  divided  into  a  collection  of  regions  labeled  according  to  the 
classification.  From  the  current  quadrant  model  analysis  in  USMC,  the  SECREPS 
for  the  LAV-25  can  be  classified  into  four  classes,  namely  ‘Routine’,  ‘Bottleneck’, 
‘Leveraged’,  and  ‘Critical’. 

In  the  current  quadrant  model  for  the  LAV-25  SECREPS,  USMC  use  variable  value 
and  risk  related  information  of  the  repairable  parts  to  build  two-by-two  matrix. 

With  this  information  that  can  be  obtained  directly  from  their  current  practice,  data 
mining  approach  can  be  considered  as  an  effective  alternative  method  for  the 
classification  of  the  SECREPS  of  the  LAV  in  maintenance  area.  Following  figure 
(6.4)  shows  the  possible  data  mining  approach  for  the  classification  of  the  LAV-25 
SECREPS. 
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Figure  6.4:  Data  Mining  Approach  for  the  Classification  of  the  LAV-25 
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7  Contemporary  Research  in  Related  Domains 

The  concept  of  autonomic  logistics  for  maintenance  envisions  an  information 
system  that  autonomously  collects,  processes  and  distributes  the  relevant  data 
across  the  entities  within  the  logistics  chain.  The  condition  based  monitoring  (CBM) 
[Appendix:  2  contain  a  list  of  websites  which  give  detailed  information  on  CBM, 
both  from  the  commercial,  DoD  and  Research  views.]  system  on  board  the  ground 
equipment  can  help  accomplish  the  task  of  acquiring  maintenance  request  data. 
This  information  has  to  be  transferred  to  the  nodes  within  the  logistics  chain  and 
should  consequently  trigger  the  fulfillment  processes.  There  is  a  need  to  develop  a 
robust  and  standardized  information  flow  that  could  render  this  possible.  Moreover, 
processes  enabling  this  have  to  be  re-engineered  to  match  the  best  practices 
prevailing  within  the  maintenance  industry  today.  This  calls  for  re-engineering  the 
existing  logistics  operations  to  fit  the  to  be  operational  architecture. 

The  key  focus  of  re-engineering  the  logistics  chain  is  to  improve  its  performance, 
flexibility,  visibility  and  readiness.  The  logistics  chain  has  to  be  systematically 
defined  by  specifying  the  different  entities  that  make  up  the  chain  and  their  inter¬ 
relationships.  Once  this  is  accomplished,  the  performance  of  the  logistics  chain 
can  be  measured  and  evaluated  using  certain  standard  metrics.  Matching  the 
current  performance  of  the  logistics  chain  with  the  benchmarked  expectations 
would  enable  us  to  control  it  by  altering  the  relationships  between  the  various 
entities  within.  Based  on  the  above-mentioned  information,  the  supply  chain 
operations  reference  model  (SCOR)  was  developed  by  the  supply  chain  council. 
The  SCOR  model  as  the  name  suggests  is  a  process  reference  model  entailing  the 
set  of  guidelines  that  help  combine  the  elements  of  business  process  re¬ 
engineering,  benchmarking  and  leading  practices  into  a  single  framework.  Under 
SCOR  supply  chain  management  is  defined  as  these  integrated  processes  -  Plan, 
Source,  Make,  Deliver  and  Return  -  from  the  supplier’s  supplier  to  the  customer’s 
customer,  all  aligned  with  the  company’s  operational  strategy,  material,  work  and 
information  flows. 

Though  the  SCOR  model  details  the  processes  and  metrics  that  can  be  adopted  to 
define  the  logistics  chain  and  evaluate  its  performance  the  following  questions 
need  to  be  answered  before  the  SCOR  project  can  be  initiated  to  identify  the 
processes  involved  and  the  corresponding  information  flows:  Should  the  entire  set 
of  processes  that  enable  supply  and  maintenance  be  viewed  as  a  single  chain?  Do 
all  the  supply  chain  threads  need  to  have  an  end-to-end  visibility?  The  quadrant 
model  is  a  logical  and  systematic  approach  that  can  be  used  to  answer  the  above 
questions.  The  products  and/or  services  moving  through  the  logistics  chain  can  be 
categorized  into  four  quadrants  and  each  quadrant  will  contain  specific  properties 
such  as  visibility,  criticality  of  the  product  etc.  This  will  help  decide  the  scope  of 
operational  visibility  required  for  each  thread  within  the  logistics  chain  and  also  to 
decide  the  priority  that  has  to  be  used  for  the  requests  of  a  specific  product  family. 
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Analyzing  the  processes  and  identifying  the  information  flows  can  facilitate  identify 
the  type  of  commercially  available  ERP  systems.  Though  these  systems  can  be 
out  into  place  seamlessly  integrating  them  into  a  single  unified,  enterprise 
application  would  prove  critical  to  the  successful  implementation.  Appendix:  10 
presents  a  detailed  review  of  the  available  literature  on  SCOR  model  as  well  as  the 
considerations  for  enterprise  application  integration.  The  references  used  to 
generate  the  document  are  also  provided  within.  It  also  looks  into  the  emerging 
trends  in  enterprise  integration  that  will  push  the  performance  levels  of  the  system 
in  the  future. 
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8  Grounding  the  Study  with  an  Exemplar 

To  ensure  that  the  study  does  not  only  consist  of  abstractions  and  can  be  related 
to  specifics  it  was  decided  to  use  a  specific  example.  The  choice  of  Light-Armored 
Vehicle  (LAV)  as  a  specific  example  was  dictated  by  several  considerations.  First, 
it  was  indicated  as  the  example  to  use  in  the  task  description.  Second,  the  LAV  is  a 
family  of  vehicles  that  has  been  in  operation  for  a  number  of  years,  is  considered 
fairly  successful  and  is  undergoing  a  service  life  extension  program  (SLEP)  making 
it  an  appropriate  candidate  for  this  project.  Third,  related  projects  for  the  LAV 
underway  at  Penn  State  ARL  and  at  Rochester  Institute  of  Technology  have 
already  undertaken  the  task  of  sensor  integration  for  health  monitoring  of  vehicles, 
which  makes  the  LAV  the  appropriate  platform  for  extending  the  work  for  the  next 
step  of  prognostics  and  diagnostics  for  a  family  of  vehicles. 

Towards  this  end,  one  of  the  members  of  the  team  has  made  contact  with  Mr. 
Deraid  Schnepp  at  the  Program  Managers  Office  for  the  LAV  at  TACOM,  Warren, 
Ml.  Following  early  discussions  with  Mr.  Schnepp,  we  have  received  a  description 
of  current  maintenance  practices,  as  documented  that  is  being  studied  by  the 
research  team.  In  addition  to  these,  the  team  is  awaiting  scheduling  of  conference 
calls  with  Gunners  at  the  PM  office,  who  are  primarily  responsible  for  maintenance 
of  the  LAV.  These  early  conversations  will  primarily  focus  on  understanding  the 
actual,  as  opposed  to  documented,  maintenance  practices  used  for  the  LAV. 
Finally,  preliminary  information  about  the  work  breakdown  structure  for  the  LAV 
has  been  obtained  from  Major  Landry  and  the  ARL  at  Penn  State  that  is  being 
studied  by  the  research  team. 
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9  Planned  Work 

Use  Case  Analysis 

1.  SECREPS  Analysis/ Data  mining 

2.  Sensor  Processing  Details 

3.  Functional  Requirements  of  IDGE 

4.  Database  Requirements 

5.  Shared  Database  Requirements/Elements 

6.  Diagnosis  Methods 

7.  Prognosis  Methods 

8.  Maintenance  Practices  and  Systems 

9.  IT  Infrastructure  Requirements 

10.  ILC-IDGE-AL  integrated  framework  -  first  cut  architecture 
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10  Questionnaire 

The  below  mentioned  questions  are  related  to  the  Quad  Model  SECREPS  data: 

1 )  What  do  the  acronym  stand  for  in  each  of  the  attributes? 

2)  What  do  they  stand  for? 

3)  Is  there  any  mathematical  formula  behind  them? 

4)  There  are  various  sheets  within  one  file;  could  you  briefly  explain  what  each 
stand  for? 

General  Questions: 

1)  What  type  and  details  of  information  do  Tactical,  Operational  and  Strategic 
levels  require? 

2)  What  are  the  various  types  of  Maintenance  systems  currently  used? 

3)  What  organizations/units  of  maintenance  comprise  within  Depot, 
Intermediate  and  Organizational  levels? 

4)  Brief  description  of  BIT/BITE  using  an  exemplar? 
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11  Appendices* 

11.1  Appendix:  1  -  OA,  ILC,  and  GCSS-MC 

1 1 .2  Appendix:  1  -  Enterprise  Architecture 

1 1 .3  Appendix:  1  -  Global  Combat  Service  Support  (GCSS-MC) 

1 1 .4  Appendix:  2  -  URLs  for  Condition  Based  Maintenance 

1 1 .5  Appendix:  3  -  Autonomic  Logistics  (AL)  on  Joint  Strike  Fighter  (JSF) 

11.6  Appendix:  4  -  Sensor 

1 1 .7  Appendix:  5  -  Condition  Based  Maintenance  in  Army 

1 1 .8  Appendix:  6  -  Commercial  Practices  of  Maintenance  in  Aviation 

1 1 .9  Appendix:  7  -  Industrial  Logistics  Applications:  Penske  Case 

11.10  Appendix:  8  -  Maintenance  and  Automotive  Telematics 

11.11  Appendix:  9  -  SCOR  model  and  EAI  system 


*  The  Appendix  is  either  a  reproduction  or  summarization  of  the  References 
mentioned  within  the  Appendix. 
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11.1  Appendix:  1  -  OA,  ILC,  and  GCSS-MC 

11.1.1  Operational  Architecture 

11.1.1  Operational  Architecture  (OA)  Review 

1 1 .1 .2  Summary  on  Integrated  Logistics  Capabilities  (ILC) 

11.1.2  Enterprise  Architecture 

1 1 .2.1  Validation  Series 

1 1 .2.2  Preliminary  thoughts  on  Condition-Based  Maintenance  (CBM) 

1 1 .1 .3  Global  Combat  Service  Support  -  Marine  Corps  (GCSS-MC) 

1 1 .3.1  Summary  on  Global  Combat  Service  Support  (GCSS) 

1 1 .3.2  Summary  on  GCCS 

1 1 .3.3  Summary  on  GCSS-MC 

1 1 .3.4  Summary  on  GCSS-MC  Strategy 

1 1 .3.5  GCSS  -  MC  Process  Summary 

1 1 .3.6  Summary  on  Autonomic  Logistics 
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11.1.1  Operational  Architecture 

1 1. 1. 1. 1  Operational  Architecture  ( OA )  Review 

This  section  depicts  the  Operational  Architecture  for  the  “To-Be”  Marine  Corps 
logistics  enterprise.  The  USMC  Integrated  Logistics  Capability  (ILC)  team  was 
tasked  to  develop  a  standard  set  of  processes  across  the  logistics  enterprise, 
based  on  ILC  concepts  and  commercial  best  practices.  First  ILC  team  developed 
the  high-level  OA  that  serves  as  the  foundation  for  the  follow-on  efforts  to  develop 
the  detailed  OA  for  Global  Combat  Support  System-Marine  Corps  (GCSS-MC). 
This  section  on  Operational  Architecture  is  organized  to  discuss  the  OA  at  a  higher 
level  of  abstraction  followed  by  a  detailed  description. 

1 1. 1. 1.2  Scope  and  approach  of  OA 


A  high-level 
business  model 
that  applied  ILC 
Business  Case 
and  SCOR  Model 
across  CSS  and 
logistics 


A  detailed 
definition  of  tasks, 
activities,  and 
information 
requirements  for 
new  logistics 
chain 

management 

processes. 


Figure  11.1:  OA  Scope  and  approach 


The  High-Level  OA  breaks  down  into  the  detailed  OA  where  tasks,  activities,  and 
information  requirements  for  new  logistics  chain  management  processes  are 
defined. 

The  high  level  view  of  the  Marine  Corps’  logistics  chain  reflects  characteristics  that 
are  similar  to  the  typical  supply  chain  existing  in  commercial  enterprises.  For 
example,  a  typical  commercial  supply  chain  is  comprised  of  two  basic  sets  of 
activities  -recognition  of  demand  for  products  and  services,  and  the  fulfillment  of 
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that  demand.  The  Marine  Corps'  logistics  chain  can  be  described  in  these  terms. 
The  consumer  creates  demand  for  products  or  services,  and  a  supplier  fulfills  that 
demand.  Despite  the  similarities  between  the  two,  the  Marine  Corps’  logistics  chain 
differs  from  the  commercial  world.  These  differences  are  directly  related  to  the 
organization,  roles,  and  mission  of  the  Marine  Corps. 

This  fact  brings  up  the  necessity  to  build  the  context-specific  detailed  OA.  The 
concepts  in  SCOR  Model  are  used  in  describing  the  details  of  the  OA.  The  SCOR 
Model  breaks  down  business  activities  that  are  associated  with  satisfying 
consumer  demand.  The  model  outlines  the  steps  of  a  logistics  chain  transaction, 
starting  with  the  consumer  inquiry  through  the  paid  invoice. 

1 1. 1. 1.3  Review  -  High  Level  OA 


Figure  11.2:  High-Level  Operational  Architecture 


The  Consumer  in  the  “To-Be”  logistics  chain  is  defined  as  the  ultimate  consumer  of 
products  and/or  services,  such  as  a  supported  unit,  and  is  depicted  as  "C"  (Figure 
11.2). 

The  consumer  is  responsible  for  generating  demands,  conducting  operator  level 
maintenance,  and  accounting  for  their  resources.  Demand  may  be  reactive  (e.g. 
unscheduled  maintenance),  or  forecasted  (e.g.  scheduled  re-supply),  using  manual 
(e.g.  radio)  and  or  automatic  (e.g.  autonomic)  modes  of  communication.  In  the  ILC 
architecture,  consumer  demands  are  passed  to  a  single  entity.  This  entity  is 
depicted  as  Supplier  1 ,  or  the  "SI"  node  (Figure  1 1 .2).  Supplier  1  is  responsible  for 


59 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  1 


all  logistics  chain  processes  including  order  management,  sourcing  and  the 
delivery  of  products  and  services  for  the  consumer.  Its  primary  obligation  is  to  fulfill 
the  demand  generated  by  the  consumer,  not  necessarily  to  maintain  a  hierarchical 
relationship  between  itself  and  its  supplier(s).  It  maintains  inventory  and  asset 
visibility,  has  intermediate  maintenance  capabilities,  and  conducts  financial 
management  for  the  consumer. 

Consumers  communicate  demand  for  products  and/or  services  to  Supplier  1  by 
any  available  means.  The  orange  arrow  in  Figure  11.2  depicts  the  information  flow. 
This  link  is  the  Consumer’s  interface  with  the  logistics  enterprise  and  includes 
other  information  such  as  order  receipt,  order  status,  and  shipping  information. 
Demand  signals  from  the  consumer  lead  ultimately  to  the  flow  of  products  and 
services  up  and  down  the  supply  chain. 

Both  product  and  service  flows  are  depicted  by  the  red  arrow.  Supplier  1  fulfills 
consumer  demands  from  organic  sources  and  is  also  responsible  for  managing 
financial  resources  for  the  consumer.  Financial  information  (e.g.,  available  funds, 
account  reconciliation,  etc.)  is  passed  onto  the  consumer.  This  flow  is  depicted  by 
the  dashed  green  line,  which  is  imbedded  within  the  information  flow  (orange  line). 

Supplier  1  is  responsible  for  communicating  with  all  other  suppliers,  vendors  and 
service  providers  (called  Supplier(s)  N,  and  depicted  as  "Sn").  Supplier(s)  N 
replenishes  demand  generated  from  the  Consumer  at  the  request  of  Supplier  1. 
Within  the  Marine  Corps,  Supplier(s)  N  activities  include  (but  are  not  limited  to) 
wholesale  supply,  depot-level  maintenance,  and  management  of  secondary 
repairables.  In  addition,  Supplier(s)  N's  involvement  with  the  logistics  chain 
enterprise  is  based  on  its  relationship  to  Supplierl.  Examples  of  Supplier(s)  N 
include  the  Defense  Logistics  Agency  (DLA),  clinical  health  care  provided  by  the 
Navy,  transportation  services  provided  by  TRANSCOM  via  GTN,  commercial 
vendors,  authorized  civilian  agencies,  or  even  adjacent  units. 

The  interaction  between  Supplier  1  and  all  other  suppliers  gives  Supplier  1  the 
ability  to  pass  a  demand  to  the  next  node  in  the  logistics  chain  (e.g.,  commercial 
vendor  or  DLA). 

A  critical  element  of  the  logistics  chain  is  the  availability  of  quality  data  across  the 
enterprise.  This  demands,  "sharing"  of  data  and  is  enabled  by  a  Shared  Data 
Environment  (SDE),  which  is  used  to  facilitate  the  flow  of  data  throughout  the 
enterprise. 

The  SDE  enables  members  of  the  logistics  enterprise  to  maintain  visibility  of 
assets  that  are  in  transit,  in  storage  and  or  in  processing,  and  provides  a  means  of 
accessing  information  by  each  node  in  the  supply  chain.  The  SDE,  which  is  the 
cornerstone  of  GCSS-MC,  provides  data  that  is  of  uniform  and  consistent  in 
structure.  The  SDE  will  also  provide  an  easily  accessible  repository  for  common 
data  necessary  to  provide  rapid,  flexible  decision  support,  total  asset  visibility,  an 
effective  planning  capability  (across  the  enterprise),  and  an  enhanced  ability  to 
execute  lifecycle  management. 
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1 1. 1. 1.4  Review  -  Detailed  OA 


Manage 


Plan 


Execute 


►  OM 


Figure  11.3:  High-Level  Functional  Context  Diagram 


We  will  briefly  explain  the  processes  in  this  section.  In  section  11.1.1.4,  we 
undertake  a  detailed  explanation.  Readers  familiar  with  the  OA  processes  can  skip 
section  1 1 .1 .1 .5. 

Logistic  Chain  Planning  (LCP)  is  located  in  the  enterprise  level.  The  duty  of  LCP 
is  planning  and  designing  logistic  chain  to  fulfill  customer’s  demands. 

Request  Management  (RM)  is  the  function  for  generating  and  approving  customer 
demands.  Basically,  it  works  by  validating  customer  requirements  and  generating 
requests  for  logistics  support  (fulfillment  of  products  and  services)  if  required.  RM 
receives  requirements  from  within  the  customer  /  supported  unit;  prioritizes 
requirements,  sources  the  demand  internally  or  processes  the  requirement  into  a 
request  and  submits  the  request  to  be  created  into  an  order. 

Order  Management  (OM)  is  the  function  for  routing,  coordinating,  tasking,  and 
tracking  customer  orders  through  fulfillment.  This  function  works  by  receiving 
requests  from  customers,  generating  customer  orders  (based  on  requests)  and 
initiating  the  fulfillment  of  products  and  services.  In  addition,  OM  processes 
communicate  order  status  to  the  customer. 

Capacity  Management  (xCM)  is  the  function  that  involves  managing,  optimizing, 
prioritizing,  and  planning  resources  and  capacity  to  fulfill  customer  demands.  It  can 
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be  divided  into  4  categories  (Distribution,  Inventory,  Maintenance  and 
Procurement)  each  category  can  again  be  divided  into  other  sub-categories. 

Production  Management  (xPM)  is  the  function  for  coordinating,  planning,  tasking 
and  controlling  how  customer  demands  are  fulfilled.  It  can  be  divided  into  4 
categories  (Distribution,  Inventory,  Maintenance  and  Procurement)  each  category 
can  then  be  divided  into  other  sub-categories. 

Execution  (xE)  is  the  function  for  executing  CSS  tasks  to  fulfill  customer  demands. 
It  can  be  divided  into  4  categories  (Distribution,  Inventory,  Maintenance  and 
Procurement)  each  category  can  be  divided  into  other  sub-categories. 


11.1.1.5  Operational  Architecture  Review:  Functional  Process 
Flows  and  Operational  Elements 

Request  Management  (RM)  is  the  function  of  generating  and  approving  customer 
demands.  Basically,  it  works  by  validating  customer  requirements  (at  an  individual 
and  aggregate  level)  and  generating  requests  for  logistics  support  (fulfillment  for 
products  and  services)  if  required.  Request  Management  is  the  customer’s 
process  of  approving  and  generating  its  demands  for  logistics  support.  RM 
receives  requirements  from  within  the  customer  /  supported  unit;  prioritizes 
requirements,  sources  the  demand  internally  or  processes  the  requirement  into  a 
request  and  submits  the  request  to  be  created  into  an  order. 

The  purpose  of  Request  Management  is  to  gather  requirements  at  an  individual  or 
aggregate  level,  validate  and  understand  the  nature  of  the  customer’s  requirement 
and  to  ensure  that  requests  for  products  and  services  can  be  supported  through 
capabilities  in  the  logistics  enterprise.  This  process  also  provides  a  means  to 
validate  requirements  at  the  aggregate  level  to  achieve  potential  economies  of 
scale  in  fulfilling  customer  requests. 

It  can  be  divided  into  4  functional  Hows: 

•  Request  Management  Product  (RMP) 

•  Request  Management  Return  (RMRL) 

•  Request  Management  Service  (RMP  (D)) 

•  Request  Management  Service  (RMP(M)) 

Order  Management  (OM)  is  the  function  of  routing,  coordinating,  tasking,  and 
tracking  customer  orders  through  to  fulfillment.  This  function  works  by  receiving 
requests  from  customers,  generating  customer  orders  (based  on  requests)  and 
initiating  the  fulfillment  of  products  and  services.  The  activities  in  the  OM  process 
enable  the  Order  Management  function  to  manage  customer  orders  from  start  to 
completion  by  coordinating  and  decomposing  requirements  with  and  among 
enterprise  capacities  and  capabilities  to  facilitate  fulfillment  of  the  order  and  to 
communicate  order  status  to  the  customer. 
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The  purpose  of  the  Order  Management  process  flow  is  to  generate  customer 
orders,  initiate  the  process  of  product  and  service  fulfillment,  and  coordinate  and/or 
decompose  all  related  logistics  activities  among  the  various  Capacity  Management 
activities.  The  Order  Management  process  binds  all  related  child  orders  to  the 
primary  order  generated  through  the  Order  Management  process.  From  the 
customer’s  perspective,  the  Order  Management  process  centralizes  the  fulfillment 
process  at  one  point  within  the  logistics  chain  enterprise  allowing  for  more 
efficiencies  and  coordinated  efforts  in  the  fulfillment  process. 

It  can  be  divided  into  5  functional  flows: 

•  Order  management  Product  (Pre  &  Post)  (OMP) 

•  Order  management  Return  (Pre  and  Post)(OMRL) 

•  Order  management  Service  (Distribution)  (Pre  and  Post)  (OMS(D)) 

•  Order  management  Service  (Maintenance)  (Pre  and  Post)(OMS(M)),  and 
Customer  Service  Management  (CUSTSRV-MGT) 

The  last  one,  Customer  Service  Management  (CUSTSRV-MGT)  is  the  process  of 
receiving,  validating,  identifying,  analyzing  and  managing  the  resolution  of 
customer  issues  or  inquiries. 

Logistic  Chain  Planning  (LCP)  is  located  in  the  enterprise  level.  The  duty  of  LCP  is 
planning  and  designing  logistic  chain  to  fulfill  customer's  demands.  LCP  can 
divided  into  11  subcategories  as  shown  below 

1.  Logistic  Chain  planning  -  Back  End  (Provider  Facing,  LCPLAN-PRO):  This 
flow  focuses  on  segmenting  providers  into  various  categories  and 
developing  appropriate  provider  relationships  with  the  goal  of  reducing  the 
total  cost  of  procurement  and  increasing  collaboration. 
Purpose:  to  establish  stronger  relationships  with  providers.  These 
strengthened  relationships  will  lead  to  improvements  in  cycle  time  and 
elimination  of  waste  that  will  result  in  increased  effectiveness  of  the  USMC 
logistics  enterprise.  This  process  also  provides  a  common  standard  for 
comparing  performance  of  various  providers  and  will  enable  the  USMC  to 
rank  and  evaluate  providers. 

2.  Logistic  Chain  planning  -  Front  End  (Customer  Facing,  LCPLAN-CUST) 
LCPLAN-CUST  is  the  process  of  establishing  customer  support  agreements, 
based  on  customer  needs  and  mission  priorities,  to  support  the  customer  in 
achieving  their  objectives.  It  helps  to  refine  the  review  process  developed  to 
understand  customer  support  requirements  and  to  provide  a  communication 
channel  for  customer  feedback. 

Purpose:  to  create  customer  support  agreements  that  will  be  used  to  define 
the  level  of  support  provided  to  help  customers  meet  their  objectives.  The 
process  also  is  used  to  refine  the  customer  support  review  process  used  to 
communicate  with  customers  and  share  requirements  both  from  a  customer 
and  a  support  capabilities  perspective. 
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3.  Network  Design  Planning  (NETDES) 

NETDES  is  the  planning  process  by  which  the  enterprise  plans  and 
manages  the  location,  capacity  and  capabilities  of  its  logistics  infrastructure. 
The  logistics  network  is  the  physical  channel  by  which  products  and 
services  are  provided  to  the  supported  unit.  Planning  is  done  to  configure 
and  reconfigure  the  nodes  and  resources  employed  in  the  logistics  chain 
network  to  optimize  its  efficiency. 

Purpose:  to  identify  additional  network  capabilities  required  to  support 
logistics  chain  goals  and  objectives.  The  logistics  network  must  effectively 
meet  the  needs  of  the  supported  unit.  Effectively  managing  the  flow  of 
product  and  services  through  the  logistics  network  is  critical  to  responding  to 
the  customer’s  requirements.  Network  design  planning  facilitates  a  cost- 
effective  and  responsive  logistics  network  to  support  the  customer. 

4.  Customer  Service  Planning  (CUSTSVRPLAN) 

CUSTSVRPLAN  is  the  process  of  capturing  and  analyzing  data  and 
developing  a  plan  to  identify  preventative  /  pre-emptive  measures  to  reduce 
or  eliminate  anticipated  service  failures  and/or  customer  issues  at  the 
enterprise  level. 

Purpose:  to  identify  service  remedy  plans  that  can  be  used  to  resolve 
customer  issues  (through  the  customer  service  management  process)  and 
to  recommend  changes  to  logistics  chain  processes  to  eliminate  or  reduce 
anticipated  service  failures. 

5.  Life  Cycle  Management  (LCM) 

Life  Cycle  Management  emphasizes  decision  processes  that  influence 
system  cost  and  usefulness  efficiencies.  The  primary  objective  of  life  cycle 
management  is  to  deliver  quality  systems  when  promised  and  within  cost 
estimates  using  an  identifiable,  measurable,  and  repeatable  process. 

6.  Maintenance  Planning  (MNTPLAN) 

MNTPLAN  is  the  process  of  determining  the  maintenance  requirements  for 
all  assets  that  need  maintenance  in  an  enterprise.  The  outcome  of  the 
Maintenance  Planning  process  is  to  conduct  preventative  maintenance  so 
that  corrective  maintenance  is  minimized.  This  approach  will  ensure  the 
highest  equipment  availability  possible  throughout  the  equipment’s  life  cycle. 
Propose:  to  plan  for  maintenance  proactively  so  that  all  the  maintenance 
requirements  over  the  long  term  (12  to  18  months)  are  gathered  and 
assessed  against  the  available  resources  at  the  enterprise  level. 

7.  Maintenance  Allocation  Planning  (MNTALC) 

MNTALC  is  the  process  of  allocating  maintenance  resources  to 
maintenance  requirements  for  all  assets  that  need  maintenance  in  an 
enterprise  over  a  regular  time  period.  Yet,  it  allocates  a  gross  requirement 
to  resources. 

Purpose:  to  provide  an  estimate  of  all  the  anticipated  maintenance 
requirements  so  that  appropriate  stakeholders  can  plan  the  use  of  their 
assets.  This  plan  will  give  stakeholders  (i.e.  operators  of  the  assets)  an 
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idea  about  when  their  assets  are  going  into  the  maintenance  cycle.  This 
also  allows  the  stakeholders  to  plan  their  resources  accordingly. 

8.  Procurement  Planning  (PROCPLAN) 

Procurement  planning  is  the  process  of  developing  a  strategy  to  replace  a 
capability  with  a  commercial  or  DoD  entity,  increase  capacity,  or  provide  a 
sourcing  strategy  to  meet  enterprise  goals. 

Purpose:  to  produce  a  Procurement  Plan  that  contains  the  activities 
required  to  modify  the  capacity  of  the  provider  and  buying  network  to  meet 
expected  logistics  chain  requirements.  These  activities  include  qualification 
of  new  providers,  identification  of  new  ways  to  purchase,  adjustment  of 
provider  contracts/agreements,  identification  of  new  products  and  services, 
etc. 

9.  Inventory  Planning  (IMPLAN) 

IMPLAN  is  the  process  of  planning  what  inventory  (by  item  /  item  category) 
is  required,  how  much  should  be  held,  where  it  should  be  held  (location)  and 
when  it  should  be  reordered  to  support  current  and  future  demands  at  the 
enterprise  level. 

Purpose:  to  meet  anticipated  demand  and  to  determine  the  business  rules 
and  control  parameters  (e.g.  order  frequency,  stock  level  thresholds,  service 
levels,  physical  properties,  etc.)  required  to  effectively  manage  an 
enterprise’s  inventory.  Ultimately,  this  process  will  help  ensure  that 
inventory  is  managed  (i.e.  positioned,  monitored,  replenished  and 
controlled)  according  to  established  logistics  chain  objectives  (i.e.  balancing 
effectiveness/efficiencies),  changing  customer  needs,  and  unexpected 
variances  in  the  demand/supply  environment. 

10.  Demand  Planning  (DEMPLAN) 

DEMPLAN  is  the  process  of  collecting,  segmenting  and  analyzing  data 
related  to  historical  planned  and  unplanned  product  and  service 
consumption,  as  well  as  known  anticipated  consumption  (e.g.  operations 
and  exercises)  at  the  enterprise  level. 

Purpose:  to  produce  a  demand  forecast  that  anticipates  future  consumption. 
This  forecast  is  based  on  the  synthesis  of  customer  and  other  segmentation 
criteria  and  enterprise  constraints  (budgetary,  regulatory  etc.);  ultimately 
resulting  in  a  forecast  that  anticipates  and  fulfills  the  demands  of  the 
customer. 

11.  Return  Planning  (RETPLAN) 

RETPLAN  is  the  process  of  collecting,  segmenting  and  analyzing  data 
related  to  historical  planned  and  unplanned  product  and  service  returns,  as 
well  as  known  anticipated  returns  at  the  enterprise  level. 

Purpose:  of  the  process  is  to  produce  a  return  forecast  that  anticipates 
future  returns  based  on  customer  and  other  segmentation  criteria.  After 
applying  constraints  (budgetary,  regulatory  etc.)  a  forecast  that  meets  the 
satisfaction  of  the  customer  can  be  used  in  the  inventory  planning  and 
service  capacity  planning  processes  to  drive  requirements. 
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Capacity  Management  (xCM)  is  the  function  that  involves  managing,  optimizing, 
prioritizing,  and  planning  resources  and  capacity  to  fulfill  customer  demands.  It  can 
be  divided  into  4  categories  (Distribution,  Inventory,  Maintenance  and 
Procurement)  each  category  can  be  divided  into  other  sub-categories  that  will  be 
described  below. 

Distribution  Capacity  Management  (PCM)  is  the  function  that  involves  managing 
and  planning  the  distribution  strategy  which  can  be  divided  into  10  functional  flows 
as  list  below. 

1.  Transportation  Planning:  Facility  Location  Capacity  Planning  (TRNS-FAC- 
LOC) 

TRNS-LOC  is  the  process  of  determining  the  location  and  capacity  of 
facilities  within  the  distribution  network.  This  process  is  primarily  driven  by 
distribution  requirements  identified  in  other  planning  processes.  The 
strategy  that  guides  this  process  is  defined  in  the  Network  Design  Plan. 
Purpose:  to  plan  for  the  necessary  facility  infrastructure  to  satisfy  projected 
distribution  requirements  within  a  particular  geographic  area.  In  this 
process,  existing  infrastructure  is  examined  and  capabilities  are  compared 
against  requirements  to  identify  excesses  or  deficiencies. 

2.  Transportation  Planning:  Transportation  Capacity  Planning  (TRNS-CAP) 
TRNS-CAP  is  the  process  of  determining  required  capacities  of  the  links 
between  nodes  within  the  distribution  network.  These  decisions  are  driven 
by  distribution  requirements  and  logistics  strategies.  Links  can  be  modified, 
added,  or  removed  to  satisfy  required  capacities. 
Purpose:  of  this  process  is  to  provide  a  way  of  examining  existing  link 
infrastructure  and  comparing  it  against  forecasted  distribution  requirements 
to  identify  future  needs.  Link  capacities  can  be  modified  to  enhance  the 
flexibility  of  the  distribution  network,  to  plan  for  contingencies  with 
alternative  options,  and  to  respond  to  changes  in  demand. 

3.  Transportation  Planning:  Facility  Resource  Planning  (TRNS-FAC-RES) 

TRNS-FAC-RES  determines  the  resource  requirements  for  facilities  that  are 
necessary  to  meet  distribution  service  demands.  This  process  takes  into 
account  various  factors  such  as  throughput  requirements,  available 
resource  options,  and  the  available  facility  budget  to  arrive  at  the  optimal 
resource  plan. 

Purpose:  to  plan  the  resources  required  to  realize  the  planned  capacity. 
Resources  are  required  at  each  facility  to  fulfill  distribution  services 
associated  with  the  facility  operating  attributes.  These  resources  can  include 
personnel,  service  equipment,  financial  budgets,  and  other  resources.  The 
quantity  of  required  resources  at  a  facility  is  dependent  on  the  distribution 
volumes,  desired  throughput  and  facility  operating  attributes. 

4.  Transportation  Planning:  Mode  Planning  (TRNS-MODE) 

TRNS-MODE  determines  the  primary  and  alternate  modes  of  transportation 
used  between  origin  /  destination  pairs,  series,  or  corridors  in  the  distribution 
network  based  on  forecasted  demand  for  distribution  sen/ices. 
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Purpose:  to  develop  a  rough  cut  plan  of  which  modes  are  most  appropriate 
to  carry  shipments  between  particular  locations  within  the  transportation 
network.  This  plan  is  used  to  guide  selection  of  compatible  routes, 
transportation  resources,  and  configuration  of  the  transportation  fleet. 

5.  Transportation  Planning:  Route  Configuration  Planning  (TRNS-ROU-CFG) 
TRNS-ROU-CFG  determines  the  primary  routes  between  Origin  / 

Destination  pairs  or  a  series  of  locations  that  can  best  satisfy  link  capacity 
requirements  identified  in  Transportation  Capacity  Planning.  This 
determination  is  based  on  various  factors  such  as  required  distribution 
volumes,  the  range  of  products  and  services  to  be  transported,  and  route 
characteristics  such  as  available  time  windows  and  vehicle  compatibility. 
Propose:  to  satisfy  the  Transportation  Capacity  Planning  with  actual  routes. 
A  route  can  be  a  series  of  roads,  airways,  sea-lanes,  or  any  other  type  of 
path  between  locations.  It  is  necessary  to  identify  multiple  routes  for  each 
transportation  link,  so  that  alternative  options  are  available  to  handle 
changes  in  volume  or  other  contingencies. 

6.  Transportation  Planning:  Fleet  Configuration  Planning  (FLEET-MGMT) 
FLEET-MGMT  determines  the  mix  of  transportation  assets  that  best 
satisfies  the  distribution  requirements,  with  consideration  to  the  other 
aspects  of  distribution  planning.  This  process  also  determines  the  pool 
points  within  the  logistics  network  where  the  transportation  fleet  should  be 
based  to  provide  the  highest  level  of  service. 

Propose:  to  generate  the  optimal  fleet  mix  (air,  ground,  etc.)  to  satisfy 
service  requirements.  The  fleet  configuration  decision  balances 
requirements  and  the  desired  service  levels  against  cost.  This  process 
studies  what  is  achievable,  and  how  to  achieve  these  goals. 

7.  Transportation  Planning:  Transportation  Allocation  Planning  (TRNS-OP) 
TRNS-OP  is  the  process  of  allocating  forecasted  distribution  volumes  to 
selected  routings  for  all  distribution  services  over  a  period  of  time.  While 
distribution  volumes  are  forecasted  across  transportation  links,  there  may 
be  multiple  routes  that  traverse  each  link.  The  distribution  capacity  for  each 
link  is  allocated  to  individual  routings  in  this  planning  process. 

Purpose:  to  refine  the  Transportation  Capacity  Plan,  using  the  Route 
Configuration  Plan  and  the  Mode  Optimization  Plan,  to  determine  how  much 
capacity  is  required  along  each  route. 

8.  Transportation  Planning  (Delivery  Planning):  Mode  Optimization  Planning 
(FLEET-MODE) 

FLEET-MODE  determines  the  optimal  and  alternate  modes  for  deliveries 
between  origin  /  destination  pairs,  series,  or  corridors  in  the  distribution 
network  based  on  distribution  scenarios. 

Purpose:  to  optimize  the  mix  of  the  modes  that  are  most  appropriate  to  carry 
shipments  between  particular  locations  within  the  transportation  network, 
after  the  fleet  mix  has  already  been  determined. 
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9.  Distribution  Capacity  Planning  (DSTCAP) 

DSTCAP  determines  the  required  capacity  within  the  area  of  operations  to 
meet  current  and  forecasted  demand.  Decisions  regarding  the  location  of 
capacity  and  the  control  parameters,  such  as  throughput,  link  and  mode 
capacity,  and  service  levels  that  are  used  to  manage  capacity,  are  also 
resolved  in  this  plan. 

Purpose:  to  plan  for  distribution  capacity  proactively  and  manage  separate 
categories  of  capacity  so  that  appropriate  business  rules  are  applied  and  a 
distribution  capacity  plan  can  be  generated. 

10.  Distribution  Capacity  /  Operations  Management  (DSTCAPOPS) 
DCTCAPOPS  is  the  process  of  scheduling  and  reserving  capabilities  and 
capacity  to  support  fulfillment  requirements  for  distribution  services.  These 
requirements  can  be  generated  by  actual  customer  demand,  or  additional 
demand  driven  by  fulfillment  of  other  services.  This  process  also  performs 
the  management  of  capacity  utilization  to  meet  established  performance 
goals  and  satisfy  changing  requirements. 

Purpose:  to  make  decisions,  (e.g.,  reservation  of  distribution  capacity  to  a 
customer  order,  relocation  of  required  resources),  to  ensure  that  the 
necessary  capacity  is  available  to  meet  demand.  This  process  also  serves 
to  coordinate  with  other  logistics  capacity  management  functions  to  ensure 
that  requirements  are  understood. 


Inventory  Capacity  Management  (ICM)  can  be  divided  into  2  subcategories  as 
described  below 

1 .  Inventory  Capacity  /  Operations  Management  (INVCAPOPS) 

INVCAPOPS  is  the  process  of  scheduling  and  reserving  capabilities  and 
capacity  to  support  overall  fulfillment  requirements  for  product  demand. 
These  requirements  can  be  generated  by  actual  customer  demand, 
additional  demand  driven  by  fulfillment  of  other  services,  or  replenishment 
requirements.  This  process  also  performs  the  management  of  capacity 
utilization  to  meet  established  performance  goals  and  satisfy  changing 
requirements. 

Purpose:  to  make  decisions  (e.g.,  reservation  of  inventory  capacity  to  a 
particular  customer  order,  relocation  or  rescheduling  of  required  resources) 
to  ensure  that  the  necessary  capacity  is  available  to  meet  demand.  This 
process  also  serves  to  coordinate  with  other  logistics  capacity  management 
functions  to  ensure  that  requirements  are  understood  and  that  the  fulfillment 
of  product  needs  to  customers  can  be  coordinated,  measured,  evaluated 
and  managed  to  meet  expectations. 

2.  Inventory  Control  /  Demand-Supply  Management  (DEMSUP) 

DEMSUP  is  the  process  of  analyzing  and  correcting  variances  in  demand 
and  supply  due  to  imbalances  between  actual  and  planned  consumption, 
and  managing  the  adjustment  of  resources  (inventories  and/or  capacities) 
required  to  correct  the  imbalance. 

Purpose:  to  account  for  inaccuracies  in  forecasted  demand  and  inventory 
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and  capacity  planning,  which  result  in  adjustments  to  inventory  and  /  or 
resources  required  for  actual  consumption  to  be  satisfied. 


Maintenance  Capacity  Management  (MCM)  can  be  divided  into  2  subcategories  as 
described  below 

1.  Maintenance  Capacity  Planning  (MNTCAP) 

MNTCAP  is  the  process  of  deciding  what  capacity  (by  type  /  category)  is 
required  and  how  much  capacity  is  needed  to  support  current  and  future 
demands.  Decisions  regarding  location  of  capacity  and  the  type  of  control 
parameters,  such  as  order  frequency,  lead-times,  service  levels,  etc.,  are 
determined  in  this  plan. 

Purpose:  to  plan  for  maintenance  capacity  proactively.  Additionally,  this 
plan  enables  the  enterprise  to  manage  separate  categories  of  capacity  so 
appropriate  business  rules  can  be  applied  and  a  Maintenance  Capacity  Plan 
can  be  generated. 

2.  Maintenance  Capacity  /  Operations  Management  (MNTCAPOPS) 
MNTCAPOPS  is  the  process  of  scheduling  and  reserving  capabilities  and 
capacity  to  support  overall  fulfillment  requirements  for  maintenance  services. 
Purpose:  of  this  process  is  to  make  decisions  (e.g.,  reservation  of 
maintenance  capacity  to  a  particular  customer  order,  relocation  or 
rescheduling  of  required  resources)  to  ensure  that  the  necessary  capacity  is 
available  to  meet  demand. 


Procurement  Capacity  Management  (PCM)  can  be  divided  into  1  subcategory  as 
described  below 

1 .  Procurement  Capacity  /  Operations  Management  (PROCAPOPS) 

PROCAPOPS  is  the  process  of  scheduling  and  reserving  capabilities  and 
capacity  to  support  overall  sourcing  requirements.  These  requirements  can 
be  generated  by  actual  customer  demand,  additional  demand  driven  by 
fulfillment  of  other  products  and  services,  or  replenishment  requirements. 
Purpose:  to  make  decisions  to  ensure  that  the  necessary  procurement 
capacity  is  available  to  meet  demand.  This  process  also  serves  to 
coordinate  with  other  logistics  capacity  management  functions  to  ensure 
that  requirements  are  understood  and  that  the  fulfillment  of  product  needs  to 
customers  can  be  coordinated,  measured,  evaluated  and  managed  to  meet 
expectations. 

Production  Management  (xPM)  is  the  function  of  coordinating,  planning,  tasking 
and  controlling  how  customer  demands  are  fulfilled.  It  can  be  divided  into  4 
categories  (Distribution,  Inventory,  Maintenance  and  Procurement)  each  category 
can  be  divided  into  other  sub-categories  that  will  be  described  below. 

Distribution  Production  Management  (PPM)  is  the  ability  to  manage  the  distribution 
strategies  after  planning  processes  are  determined.  It  can  be  divided  into  2 
subcategories  of  functional  flows  as  described  below. 
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1 .  Distribution  Production  /  Operations  management  (DSTOPS) 

DSTOPS  is  the  process  of  scheduling  and  reserving  specific  resources  to 
support  overall  fulfillment  requirements  for  distribution  services.  In  addition, 
the  Distribution  Operations  Management  function  will  also  adjust  schedules 
and  or  resources  according  to  feedback  from  the  execution  function. 
Purpose  of  this  process  is  to  make  decisions,  (e.g.,  reservation  of  specific 
distribution  resources  to  a  particular  customer  order,  relocation  or 
rescheduling  of  required  resources),  to  ensure  that  the  necessary  resources 
are  available  to  meet  demand. 

2.  Transportation  Planning  (Delivery  Planninq)  -  Route  and  Schedule  Planning 
(TRNS-ROU-SCH) 

TRNS-ROU-SCH  determines  the  primary  routes  and  schedules  for  the 
delivery  of  products  and  services.  Running  various  scenario  driven  models 
and  selecting  the  best  solution  determines  the  planned  routes  and 
schedules. 

Propose:  to  establish  a  schedule  for  the  execution  of  distribution  tasks  or 
deliveries.  This  process  covers  scheduling  and  routing  of  deliveries  for  the 
logistics  enterprise  to  meet  distribution  requirements  generated  by  Inventory 
Planning,  Maintenance  Planning,  and  other  planning  processes.  The 
schedule  solution  should  be  designed  in  accordance  with  vehicle 
maintenance  requirements,  mode  capabilities,  and  operator  limitations  such 
as  the  maximum  number  of  driving  hours/day. 


Inventory  Production  Management  (IPM)  is  the  ability  to  manage  the  inventory 
strategies  after  planning  processes  are  determined.  It  can  be  divided  into  1 
subcategory  of  functional  flows  as  described  below. 

1 .  Inventory  Production  /  Operations  Management  (INVOPS) 

INVOPS  is  the  process  of  scheduling  and  reserving  specific  resources  to 
support  overall  fulfillment  requirements  for  product  demands.  In  addition, 
the  Inventory  Operations  Management  function  will  also  adjust  schedules 
and  /  or  resources  according  to  feedback  from  the  execution  function. 
Purpose:  to  make  the  management  decisions,  around  inventory  execution, 
required  to  ensure  the  necessary  resources  are  available  to  meet  demand 
for  product  fulfillment. 


Maintenance  Production  Management  (MPM)  is  the  ability  to  manage  the 
maintenance  strategies  after  planning  processes  are  determined.  It  can  be  divided 
into  2  subcategories  of  functional  flows  as  described  below. 

1 .  Maintenance  Production  /  Operations  Scheduling  (MNTSCH) 

MNTSCH  is  the  process  of  scheduling  maintenance  resources  against 
specific  assets  that  need  maintenance.  The  Maintenance  Allocation  Plan 
drives  the  scheduling  process.  The  Maintenance  Scheduling  process 
commits  resources  to  specific  tasks  with  specific  time  associated  with  each 
item  so  that  maintenance  is  performed  at  a  scheduled  time 
Purpose:  to  schedule  equipment  for  maintenance  at  specific  dates  and 
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times.  This  process  bridges  the  gap  between  the  Maintenance  Allocation 
and  the  Maintenance  Operations  processes  and  can  be  viewed  as  a  further 
decomposition  of  the  “Schedule  and  Reserve  Specific  Resources”  activity  in 
the  Maintenance  Operations  Management  process  flow. 

2.  Maintenance  Production  /  Operations  Management  (MNTOPS) 

MNTOPS  is  the  process  of  scheduling  and  reserving  specific  resources  to 
support  overall  fulfillment  requirements  for  maintenance  services.  In 
addition,  the  Maintenance  Operations  Management  function  will  also  adjust 
schedules  and  or  resources  according  to  feedback  from  the  execution 
function. 

Purpose:  to  make  decisions  (e.g.,  reservation  of  specific  maintenance 
resources  to  a  particular  customer  order)  to  ensure  that  the  necessary 
resources  are  available  to  meet  demand.  This  process  coordinates  with  the 
Maintenance  Capacity  Management  function  to  ensure  that  requirements 
are  understood  and  that  the  fulfillment  of  maintenance  services  to 
customers  can  be  measured  evaluated  and  managed  to  meet  customer 
expectations  (quality  order  concept). 


Procurement  Production  Management  (PPM)  is  the  ability  to  manage  the 
maintenance  strategies  after  planning  processes  are  determined.  It  can  be  divided 
into  1  subcategory  of  functional  flows  as  described  below. 

1 .  Procurement  Production  /  Operations  Management  (PROCOPS) 

PROCOPS  is  the  process  of  training  and  applying  sufficient  resources  to 
execute  procurement  actions  based  on  the  anticipated  volume  and 
complexity  of  the  requirements.  In  addition,  the  Procurement  Operations 
Management  function  will  also  adjust  schedules  and  or  resources  according 
to  feedback  from  the  execution  function. 

Purpose:  to  manage  the  execution  of  procurement  actions  based  off  the 
procurement  plan  to  ensure  that  the  necessary  resources  are  available  to 
fulfill  product  and  service  demands.  This  process  coordinates  with  the 
procurement  capacity  management  function  to  ensure  that  requirements  are 
understood. 


Execution  (xE)  is  the  function  of  executing  CSS  tasks  to  fulfill  customer  demands. 
It  can  be  divided  into  4  categories  (Distribution,  Inventory,  Maintenance  and 
Procurement)  each  category  can  be  divided  into  other  sub-categories  that  will  be 
described  below. 

Distribution  Execution  (DE)  is  the  execution  of  distribution  strategy  to  fulfill  the 
customer  demands  which  can  be  divided  into  1  subcategory  as  described  below. 

1.  Distribution  Fulfillment  (OFS(D)) 

OFS(D)  is  the  process  of  executing  distribution  as  part  of  a  customer  order 
for  products  and  services.  Distribution  fulfillment  may  entail  delivering  a 
product  to  a  customer  or  include  transportation  of  equipment.  Distribution 
fulfillment  is  also  the  process  used  to  move  the  customer  and/or  equipment 
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to  another  location. 

Purpose:  to  execute  distribution  of  product  and  resources  to  meet  customer 
requirements  for  product  and  service  fulfillment. 

It  also  related  to  a  customer  requirement  for  product  or  services,  begins  with 
a  service  order  linked  to  a  customer  order.  The  service  order  may  have 
been  initiated  due  to  a  product  or  returns  order,  due  to  a  maintenance 
service  order,  or  due  to  some  other  customer  need  requiring  distribution 
services.  The  service  order  may  also  be  a  request  for  transportation 
services  not  related  to  product  or  services  fulfillment,  (i.e.  movement  of 
personnel,  equipment  or  a  stand  alone  transportation  order). 


Inventory  Execution  (IE)  is  the  execution  of  inventory  strategy  e.g.  packing,  picking 
items  to  fulfill  the  customer  demands  which  can  be  divided  into  2  subcategories  as 
described  below. 

1.  Warehouse  Management  Outbound  (WMO) 

WMO  is  the  process  of  picking,  packing  and  shipping  items  for  fulfillment  of 
customer  orders  or  replenishment  of  inventories  at  other  locations. 

Purpose:  to  execute  the  outflow  of  items  from  a  location  for  fulfillment  of 
existing  and  anticipated  product  orders  either  initiated  through  a  product  or 
service  order. 

2.  Warehouse  Management  Inbound  (WMI) 

Inbound  Warehouse  Management  is  the  process  of  receiving  items  from 
providers  (internal  and  external),  verifying  and  recording  assets  received, 
recording  and  reporting  discrepancies  and  storing  the  items  for  the 
fulfillment  of  anticipated  customer  orders.  The  process  includes  cross¬ 
docking  operations  for  the  fulfillment  of  existing  customer  orders. 

Purpose:  to  execute  the  inflow  of  items  from  internal  and  external  providers 
and  to  ensure  that  the  items  are  appropriately  stored  for  fulfillment  of 
existing  and  anticipated  customer  orders  initiated  through  a  product  or 
service  order. 


Maintenance  Execution  (ME) 

1.  Maintenance  Fulfillment  (OFS(M)) 

OFS(M)  is  the  execution  of  inventory  strategy  e.g.  packing,  picking  items  to 
fulfill  the  customer  demands  which  can  be  divided  into  2  subcategories  as 
described  below. 

Purpose:  to  identify  the  activities  necessary  to  fulfill  any  maintenance 
demand  that  has  been  initiated  through  the  logistics  chain  enterprise.  The 
activities  identified  in  the  flow  represent  the  execution  component  of  the 
maintenance  process. 


Procurement  Execution  (PE) 
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1 .  Procurement  Execution  Fulfillment  (PROCFUL) 

PROCFUL  is  the  process  of  fulfilling  sourcing  requirements  for  products  and 
services  that  originate  either  through  order  fulfillment  or  through  inventory 
replenishment. 

Purpose:  to  fulfill  sourcing  requests,  using  the  most  appropriate  providers 
and  options  and  leveraging  existing  /  new  options  and  capacities.  This 
process  also  tracks  the  progress  of  a  sourcing  request(s)  through  to 
satisfaction  of  the  sourcing  requirement. 

11.1.2  Summary  on  Integrated  Logistics  Capabilities  (ILC) 

The  Integrated  Logistics  Capabilities  (ILC)  effort  began  in  1998  as  a  unique 
collection  of  military,  industry  and  academic  organizations  collaborating  to  develop 
a  future  vision  of  Marine  Corps  logistics  processes.  In  this  effort,  a  transformation 
strategy  based  on  best  practices  in  industry  is  implemented  to  provide  the 
framework  for  the  execution  of  agile,  effective  logistics  support  to  the  Marine  Air- 
Ground  Task  Force.  Since  one  of  the  fundamental  advantages  that  the  Marine 
Corps  maintains  over  other  service  components  is  the  ability  to  provide  self- 
sufficient,  expeditionary  logistics  support,  the  era  of  Marines  satisfying  complex 
logistics  problems  with  mass  (people,  supplies,  and  equipment)  has  passed. 
Transformation  to  meet  the  challenges  of  tomorrow  is  a  fundamental  objective  for 
the  ILC. 

ILC  is  a  key  concept  for  US  Marine  Corps  to  revolutionize  its  logistics  supply  chain 
during  this  era  of  information  technology.  The  philosophy  behind  ILC  is  to  enable 
the  maintenance  of  a  Shared  Data  Environment  (SDE)  and  further  enterprise-wide 
planning  based  on  real  time  and  accurate  information,  so  that  the  holistic  metrics  of 
a  global  supply  chain  can  be  optimized.  Until  now,  the  ILC  team  in  US  Marine 
Corps  has  developed  Enterprise  Architecture,  especially  high-level  operational 
architecture,  and  some  validation  series. 


11.2  Appendix:  1-  Enterprise  Architecture 

Architecture  can  be  described  with  the  combination  of  three  major  views: 
operational,  systems,  and  technical  views.  The  Marine  Corps  integrated  logistics 
system  is  not  an  exception.  The  operational  architecture  view  is  a  description  of 
the  tasks  and  activities,  operation  elements,  and  information  flows  required  to 
accomplish  or  support  a  military  operation.  The  system  architecture  view  is  a 
description,  including  graphics,  of  systems  and  interconnections  providing  for,  or 
supporting,  warfighting  functions.  The  technical  architecture  view  is  the  minimal  set 
of  rules  governing  the  arrangement,  interaction,  and  interdependence  of  system 
parts  or  elements,  whose  purpose  is  to  ensure  that  a  conformant  system  satisfies  a 
specified  set  of  requirements.  In  a  word,  the  operational  view  identfies  warfighter 
relationships  and  information  needs;  the  systems  view  relates  capabilities  and 
characteristics  to  operational  requirements;  the  technical  view  prescribes 
standards  and  conventions.  The  development  of  ILC  provides  the  ontology  for 
different  views  with  graphical  and  text  primitives.  Currently,  the  development  of  the 
operational  view,  i.e.  ILC  high-level  OA,  has  been  completed  due  to  the  completion 
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of  the  operational  architecture.  However,  the  development  of  the  systems  and 
technical  views  are  left  for  the  future  work. 

The  ILC  high-level  OA  integrates  current  CSS/logistics  functions  with  common, 
high-level  management  processes  based  upon  a  universal  supply-chain  model. 
The  “To-Be”  ILC  high-level  OA  provides  an  enterprise  wide,  integrated  view  of 
logistics  focused  on  fulfillment  of  the  demands  for  products  and  services  generated 
by  the  warfighter.  The  approach  used  for  developing  ILC  high-level  OA  adopts  the 
Supply  Chain  Operational  Reference  (SCOR)  model.  Rather  than  concentrate  on 
the  vertical  or  functional  “stove  pipes”  of  the  current  logistics  enterprise,  the  OA 
team  employed  a  horizontal  or  process-oriented  view  across  all  of  Marine  Corps 
logistics. 

The  high-level  operational  concept  description  is  summarized  in  the  following.  The 
Consumer  is  defined  as  the  ultimate  consumer  of  products  and/or  services,  and  is 
depicted  as  “C”.  Its  main  responsibilities  include  demand  generation,  operator  level 
maintenance,  and  accountability.  Consumer  demands  are  passed  to  a  single  entity. 
This  entity  is  depicted  as  Supplier  1,  or  the  “SI”  node.  Supplier  1’s  responsibilities 
include  demand  fulfillment,  all  CSS  functions,  intermediate  level  maintenance  and 
financial  management.  The  flows  between  a  “C”  node  and  a  “SI”  node  can  be 
product  and/or  service,  information  (including  financial  information)  flows. 

Supplier  1  is  responsible  for  communications  with  all  other  suppliers,  vendors  and 
service  providers,  which  are  called  Supplier(s)  N,  depicted  as  “Sn”.  Supplier(s)  N’s 
responsibilities  include  demand  fulfillment,  SECREP  (Secondary  Repairable) 
Management  and  depot  level  maintenance.  The  flows  between  a  “SI"  node  and  a 
“Sn”  node  can  be  product/service,  information  and  financial  flows.  In  some  cases, 
there  may  a  direct  product/service  flow  between  a  “Sn”  and  “C”  nodes,  although 
the  “SI”  node  has  to  be  informed. 

From  the  above  description,  the  ILC  high-level  OA  requires  the  flow  of  data 
throughout  the  enterprise.  It  is  enabled  by  a  Shared  Data  Environment  (SDE).  The 
SDE  consists  of  four  layers,  which  are  infrastructure  layer,  data  layer,  system  layer 
and  part  of  the  business  layer,  from  the  bottom  to  the  top.  The  representatives  in 
the  infrastructure  layer  are  computer  system  and  network  devices.  In  the  data  layer, 
database  and  flat  file  systems  store  all  the  necessary  data  and  information.  In  the 
system  layer,  application  servers  and  database  management  systems  provides  the 
tools  for  the  extraction  and  query  of  information.  In  the  business  layer,  business 
rules  are  defined  as  the  bridge  between  the  system  layer  and  the  presentation 
layer,  which  defines  enterprise  portal.  The  SDE  is  depicted  in  Figure  1 1 .4. 

The  SDE  enables  real  time  supply  chain  planning  based  on  current  and  accurate 
information.  To  facilitate  the  planning  process,  data  from  the  execution  activities 
can  be  fed  back,  via  the  SDE,  to  the  planning  elements  throughout  the  supply 
chain.  This  creates  a  continuous,  cyclical  flow  of  information  between  plan  and 
execution  activities. 
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In  summary,  the  high-level  operational  concept  graphic  depicts  a  logistics 
enterprise  that  is  optimized  for  a  deployed  environment,  provides  a  clear  customer 
focus  enabled  by  standard  processes,  well-defined  activities  and  integrated 
information  technology  in  an  SDE. 
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Figure  11.4:  Architecture  of  SDE 


11.2.1  Validation  series 

The  Validation  Series  is  a  phased  implementation  of  process  improvements  and 
Information  Technology  through  a  series  of  real  world  requirements  validation 
initiatives  within  the  Operating  Forces.  The  Validation  series  is  an  iterative  process, 
a  continuous  implementation  and  refinement  of  efforts  designed  to  demonstrate 
the  vision  of  enhanced  and  more  responsive  logistical  support  to  the  MAGTF.  Key 
metrics,  developed  in  conjunction  with  the  OA,  will  allow  the  Marine  Corps  to 
measure  the  benefits  and,  if  necessary,  make  course  corrections  to  logistics 
processes,  as  required.  In  the  following,  key  metrics  and  three  analysis 
assessments  by  Navy  are  summarized. 

Currently,  the  Marine  Corps  uses  numerous  metrics  to  measure  everything  from 
how  many  miles  material  has  been  transported  (Ton  Miles);  to  the  number  of 
orders  that  are  filled  from  inventory  on  hand.  To  evaluate  the  ILC  concept,  they 
defined  six  categories  of  metrics:  reliability,  responsiveness,  flexibility,  readiness, 
assets  and  expense. 
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Reliability  is  measured  by  Quality  Order  Fulfillment.  Responsiveness  is  measured 
by  Total  Logistics  chain  Cycle  Time.  Logistics  chain  flexibility  is  prescribed  by  the 
capacity  available  to  handle  sudden  demand  surges.  Operational  Availability  metric 
has  been  selected  as  the  Readiness  attribute's  tier-one  metric.  Assets  are 
measured  by  Asset  Utilization.  The  proposed  expense  metric  is  Total  Logistics 
chain  Expense. 

Navy  produced  three  assessment  reports,  which  are  summarized  in  the  following. 
Their  analysis  shows  that  ILC  enables  great  improvement  on  their  logistics  supply 
chain. 

In  the  interim  assessment,  they  report  the  following  results: 

•  Improved  supply  response  time 

•  Improved  overall  repair  cycle  time 

•  Delta  TAMCN  (Table  of  Allowance  Material  Control  Number)  readiness 
rebounding 

•  Indications  that  maintenance  quality  may  improve  in  future  through 

improved  training  of  maintenance  personnel 

•  However,  customer  satisfaction  with  logistics  support  has  declined 

In  the  first-year  assessment,  the  following  results  are  observed: 

•  Improved  supply  response  time 

•  Improved  overall  repair  cycle  time 

•  No  significant  changes  in  readiness 

•  Indications  that  maintenance  quality  may  improve  in  future  through 

improved  training  of  maintenance  personnel 

•  Customer  satisfaction  with  logistics  support  has  declined,  though  there  are 
recent  signs  of  improvement 

In  the  mid-term  assessment,  the  following  results  are  obtained: 

•  Materiel  readiness  rates:  Readiness  rates  stayed  fairly  constant  for  all 
except  Delta  TAMCNs. 

•  Repair  cycle  time:  median  RCT  tends  to  be  a  slight  decrease  and  95th 
percentile  shows  a  dramatic  drop  (from  214  to  134  days). 

•  Number  of  repair  tasks:  the  number  of  repair  tasks  per  personnel  has  been 
dramatically  increased  (234%). 

•  Supply  response  time:  The  median  supply  response  time  has  decreased.  It 
is  observed  that  a  drastic  reduction  in  the  variability  of  supply  response  time 
during  the  last  few  months  as  compared  to  the  baseline  period. 

•  Time  allocation  (maintenance):  no  apparent  improvement 

•  Training  quality  for  maintenance  personnel:  more  Marines  are  working  on 
duties  within  their  MOS  (Military  Occupational  Specialties)  than  before.  In 
addition,  in  many  cases,  confidence  in  performing  ITSs  (Individual  Training 
Standards)  within  individual  MOSs  has  increased. 

•  Time  allocation  (supply):  the  total  amount  of  time  spent  by  supply  personnel 
on  supply  activities  remains  between  45  percent  and  55  percent  of  their  time 
at  work.  However,  the  amount  of  time  spent  on  warehouse  activities 
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increased  substantially,  compared  to  the  baseline,  while  the  amount  of  time 
spent  on  property  control  decreased. 

•  ‘Quality’:  The  percentage  of  respondents  rating  overall  quality  of 
maintenance  support  either  poor  or  fair  rose  to  46%,  compared  to  22%  in 
the  baseline.  At  the  same  time,  the  percentage  rating  overall  support  either 
good  or  excellent  dropped  to  16%  from  46%. 


11.2.2  Preliminary  thoughts  on  Condition-Based  Maintenance  (CBM) 

In  the  development  of  condition-based  maintenance  system,  ILC  concept, 
especially  its  SDE  and  enterprise-wide  planning,  can  be  very  useful.  The  SDE  will 
enable  the  sensor  and  diagnostics  information  to  be  effectively  stored  and 
accessed.  The  key  point  of  SDE  is  to  provide  the  decision  makers  transparent 
visibility.  The  enterprise-wide  planning  system  is  a  real  time  scheduling  system, 
which  bring  intelligence  to  the  supply  chain.  Hopefully,  high-performance  anytime 
algorithms  that  have  the  ability  to  keep  the  virtual  plans  can  be  developed  to  make 
full  use  of  the  real  time  and  accurate  information.  The  detailed  ideas  will  be 
presented  in  the  future. 
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ILC  Operational  Architecture  -  OV-1 
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Figure  11.5:  ILC  high-level  OA 


11.3  Appendix:  1-  Global  Combat  Service  Support  -  Marine  Corps 
(GCSS-MC) 


11.3.1  Summary  on  Global  Combat  Service  Support  (GCSS) 

The  Global  Combat  Support  System  (GCSS)  is  a  Family  of  Systems  that  provides 
information  interoperability  across  combat  support  functions  and  between  combat 
support  and  command  and  control  functions  in  support  of  the  Joint  War  Fighter. 
GCSS  is  the  war  fighter’s  tool  to  capture  essential  data,  transform  it  into  usable 
information,  and  gain  information  superiority  to  the  success  of  maintaining  force 
readiness  and  winning  Nation’s  conflict.  It  focuses  on  the  existing  applications  and 
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is  geared  to  support  seamless  transition  between  peacetime  and  contingency 
operations.  GCSS  is  therefore  a  critical  component  in  supporting  Command, 
Control,  Communications,  Computing  and  Intelligence  Warrior  (C4IFTW). 

GCSS  vision  encompasses  six  essential  attributes: 

•  Any  box  (computer)  -  is  the  result  of  Common  Operating  Environment 
(COE)  to  over  come  the  incompatibility  of  different  operating  systems. 

•  Any  authorized  user  -  refers  to  the  benefit  of  using  common  screens  on  any 
workstations  to  reduce  training. 

•  One  net  -  refers  to  the  ultimate  availability  of  all  war  fighter  functions  from  a 
single  workstation. 

•  One  picture  -  refers  to  the  capability  to  integrate  information  across 
functional  areas,  combat  support,  and  command  and  control. 

•  Common  services  -  include  basic  computing  requirements  such  as  printer, 
sound,  and  communication  interfaces  within  the  COE.  Other  common 
services  include:  forms  and  reports  generators,  database  search  and 
extraction  tools  and  business  process  servers. 

•  Robust  communications  infrastructure  -  encompasses  all  of  the  networks, 
pipelines,  and  hardware  necessary  to  provide  global,  near  real-time  access 
or  situational  awareness  of  information. 

•  Anywhere  -  means  that  we  can  access  GCSS  from  any  geographic  location. 

One  of  the  first  capabilities  or  applications  to  be  made  available  via  GCSS  is  asset 
visibility  -  the  capability  to  provide  users  with  timely  and  accurate  information  on 
the  location,  movement,  status  and  identity  of  units,  personnel,  equipment  and 
supplies.  Presently,  Joint  Total  Asset  Visibility  (JTAV)  will  incorporate  some  other 
key  logistical  functions  of  supply,  maintenance  and  transportation  and  will  be  a 
very  valuable  tool  for  the  war  fighter. 

A  critical  element  of  GCSS  will  be  the  ability  to  manage  and  manipulate  data  into  a 
usable  format  for  the  war  fighter.  Joint  Decision  Support  Tools  (JDST)  are 
computer  tools  and  processes  that  will  meet  CINC  and  user  requirements  to  plan, 
execute,  monitor  and  plan  logistics  operations  and  provide  a  common  operating 
picture  of  the  battle  space. 


11.3.2  Summary  on  GCCS 

GCSS  merges  with  the  Global  Command  and  Control  Systems  (GCCS)  where 
GCSS  provides  combatant  commands  and  Joint  Force  Commanders  (JFCs)  the 
ability  to  provide  military  information  rapidly  to  the  National  Command  Authorities 
(NCA),  as  well  as  to  the  other  supporting  commands.  Both  GCSS  and  GCCS  will 
provide  Command  and  Control,  Communications,  Computers,  Intelligence, 
Surveillance,  and  Reconnaissance  for  the  Warfighter  (C4ISFTW).  Whereas  GCCS 
concentrates  heavily  on  operations,  GCSS  focuses  on  the  combat  support  or 
logistical  requirements  of  the  warfighter.  The  convergence  of  both  systems  will 
provide  situational  awareness  via  a  fused  real-time,  view  of  the  battlespace  for  any 
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mission.  GCSS  results  in  near  real-time  command  and  control  of  the  logistics 
pipeline;  one  fused  picture  of  combat  support  to  the  warfighter,  and  a  closed  link 
between  command  and  control  and  combat  support  during  the  execution  of  any 
operation  or  mission  in  support  of  the  Joint  Warfighter. 

11.3.3  Summary  on  GCSS-MC 

One  of  the  components  of  DoD  GCSS  is  the  GCSS-MC.  GCSS-MC  is  the 
information  tool  that  provides  logistics  operators,  planners  and  the  warfighter,  at 
the  joint  and  Marine  Corps  levels,  a  fused,  integrated,  real-time,  accurate  logistics 
picture  thereby  enabling  visibility  into  and  control  of  the  logisitcs  pipeline.  (Control 
is  done  through  electronic  collaboration  visibility,  use  of  joint  decision  support  tools, 
and  autonomous  and  real-time  updates). 

GCSS-MC  includes  only  one  server  and  associated  peripherals.  Navy  Marine 
Corps  Intranet  (NMCI)  provides  connectivity  of  this  equipement  to  the  network  for 
use  by  all  authorized  personnel  with  garrison.  Components  of  GCSS-MC  will 
reside  on  both  the  Non  Secure  Internet  Protocol  Router  Network  (NIPRNET)  and 
the  Secure  Internet  Protocol  Router  Network  (SIPRNET)  and  they  are  unclassified. 

(Note:There  will  be  a  one-way  interface  from  the  NIPRNET  to  the  SIPRNET  via  a 
Guard  interface.  All  transactional  systems  will  reside  only  on  NIPRNET.  Some 
logistics,  operational  and  planning  data  is  classified.  Some  of  the  unclassified  data 
aggregated  becomes  classified  will  reside  on  the  SIPRNET). 


1 1 .3.4  Summary  on  GCSS-MC  STRATEGY 

The  GCSS-MC  Strategy  is  composed  of  three  fundamental  approaches: 

•  Management  -  Provides  overall  direction  and  alignment  of  the  program  and 
ensuring  buy-in  across  the  Marine  Corps  and  DoD.  Make  necessary  trade¬ 
offs  between  requirements,  solutions  and  funding  to  ensure  optimal  results. 

•  Functional  -  Ensures  both  Warfighter  and  Service  needs  are  refined  into 
system  and  functional  requirements  and  that  the  solutions  are  continually 
aligned  with  expectations  amongst  all  stakeholders. 

•  Technical  and  System  -  Ensures  a  solution  is  implemented  that  meets  the 
Warfighter  and  Service  requirements  within  a  best  fit  for  the  Marine  Corps  in 
terms  of  culture,  economy,  reliability,  and  robustness. 

These  three  main  approaches  to  the  GCSS-MC  strategy  are  intended  to  provide 
the  Marine  Corps  and  DoD  with  a  product  that  satisfies  warfighter  needs  within  the 
desired  schedule  and  to  a  satisfactory  level  of  quality.  These  approaches  are 
described  in  more  detail  below. 

Management 

Marine  Corps  Systems  Command  has  empowered  the  GCSS-MC  Management 
Team  (GMT),  with  a  chartered  role  to  manage,  plan,  coordinate  and  synchronize 
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the  overall  GCSS-MC  effort.  The  primary  objective  of  the  GMT  is  to  ensure  defined 
requirements  supporting  logistics  transformation  objectives  identified  by  the 
Integrated  Logistics  Capability  (ILC)  analysis,  and  those  requirements  as 
mandated  by  the  Department  of  Defense  for  GCSS  implementation.  The  GMT  is 
composed  of  Marine  Corps  Systems  Command  personnel  and  functional 
representatives  and  is  committed  to  ensure  the  technical  effort  of  GCSS-MC  is 
aligned  and  tightly  linked  to  the  objectives  and  functional  requirements  of  the 
Functional  Advocates.  A  critical  role  of  the  GMT  is  to  establish  the  ongoing 
communications  with  stakeholders  to  ensure  all  parties  are  engaged  and 
committed  to  a  common  GCSS-MC  goal. 

The  GMT  will  manage  GCSS-MC  as  a  portfolio  of  systems.  Each  system  and 
related  effort  will  be  executed  as  a  separate  project.  The  theme  is  to  provide 
central  coordination  and  technical  oversight,  but  to  decentralize  execution  of  the 
effort  across  managed  projects  and  related  efforts.  To  accomplish  this, 
development  will  primarily  follow  a  bottoms-up  approach  within  the  portfolio  of 
systems  and  programs  of  record  with  each  sub-team  or  sub-project  executing  their 
portions  of  the  overall  plan.  The  overall  GCSS-MC  plan  will  be  elaborated  over 
time  with  a  top-down  view  using  a  rolling  wave  planning  approach.  Therefore,  the 
near  term  plan  will  be  developed  in  detail  with  future  activities  less  detailed.  As 
more  information  becomes  known,  the  plan  is  elaborated.  Generally,  each  current 
phase  will  have  a  detailed  project  plan  and  work-breakdown  structure  and  the  next 
phase  of  the  plan  will  be  in  an  elaboration  state.  The  management  approach  will 
also  work  within  the  current  framework  of  many  concurrent  parallel  efforts  and 
studies.  The  GMT  will  seek  to  integrate  these  activities  into  a  cohesive  program. 

The  strategy  to  achieve  the  GCSS-MC  vision  is  based  on  actively  maintaining  a 
view  of  the  desired  end-state.  This  includes  the  planning  and  preparation  to 
effectively  build  and  operate  the  high  availability,  enterprise-level  system  and 
technical  architecture  necessary  to  provide  a  secure,  global  environment  with  an 
enterprise  view  of  data  able  to  provide  near  real-time  information  to  the  warfighter. 
The  key  is  insuring  establishment  of  well-managed  systems  and  responsive 
services  needed  to  provide  the  high  level  of  confidence  required  by  system  users. 
Security  planning  is  an  integral  up-front  design  process.  The  GMT  will  ensure 
GCSS-MC  compliance  through  a  series  of  synchronized  planning  and  coordination 
activities  focused  on  achieving  the  architected  vision.  The  team  will  actively 
coordinate  with  technical  organizations  such  as  the  Marine  Corps  PKI  CAC 
programs,  NMCI,  PM  Radio,  and  DISA,  particularly  in  the  areas  of  system 
requirements  and  security  certifications.  This  activity  will  focus  on  information 
sharing  related  to  common  critical  events  that  impact  acquisition  strategies  and 
schedules  or  represent  an  increased  degree  of  risk  for  dependent  events  and 
GCSS-MC  development  and  fielding  considerations.  In  addition,  the  GMT  will 
strive  to  work  with  other  organizations  that  may  experience  the  enterprise-wide 
impact  GCSS-MC  will  have  as  it  is  adopted  by  the  logistics  community. 
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Figure  11.6:  Framework  -SDE 

As  GCSS-MC,  is  the  physical  Implementation  of  the  ILC  and  the  capability  to  meet 
CINC  warfighter  needs,  the  GCSS-MC  team  will  be  working  closely  with  the  ILC  as 
re-engineers  business  processes.  These  are  expected  to  yield  direct  benefits  to 
the  Marine  Corps  such  as  reduced  customer  wait  time,  reduced  inventories. 
Indirectly,  the  process  will  result  in  trading  MAGTF  mass  and  footprint,  for 
information  and  speed.  A  critical  initial  step  of  GCSS-MC  will  be  translating 
requirements  from  the  ILC  into  actionable  system  functional  requirements. 
Similarly,  selected  CINC  129  requirements  will  be  a  Marine  Corps  responsibility 
and  they  will  be  assessed  against  current  and  planned  systems  and  process 
capabilities.  The  effort  will  also  include  an  activity  to  identify  current  Marine  Corps 
portfolio  gaps,  and  a  Plan  of  Action  and  Milestones  to  meet  those  requirements 
through  a  variety  of  technical  approaches.  This  includes  the  Shared  Data 
Environment  (SDE)  [Figure  1.6],  which  represents  a  tool  for  meeting  decision 
support  and  data  access  needs  whose  specific  requirements  require  significant 
analysis  and  exploration. 

A  key  tool  in  the  functional  strategy  will  be  the  use  of  pilot  sites,  ACTDs  (Advanced 
Concept  Technology  Demonstration)  and  proofs  of  concept  to  generate,  validate, 
and  test  the  requirements  and  revised  business  processes.  Where  appropriate  the 
GCSS-MC  team  will  conduct  metrics-based  evaluation  of  programs  of  record 
versus  other  COTS  and  GOTS  products  for  fit  within  the  overall  objective  and  to  fill 
gaps.  Recognized  off-the-shelf  capabilities  will  be  evaluated  as  "buy"  options  for 
trade-off  analysis  against  the  "make"  option,  in  the  case  where  existing  systems 
may  require  extensive  rework  or  there  is  a  clear  gap  in  current  system  capabilities. 

Technical  and  System  Strategy 

The  GCSS-MC  technical  and  system  strategy  is  intended  to  ensure  that  systems, 
applications,  and  related  technical  infrastructure  support  the  functional  and  system 
requirements  of  the  ILC  and  DoD  within  affordability  and  supportability  criteria  as 
established  by  the  Functional  Advocates.  The  result  will  be  an  architecture 
comprising  Systems,  Operational  and  Technical  views  that  best  meet  the  Marine 
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Corps'  objectives  and  culture.  This  objective  can  be  described  broadly  as  a  family 
of  systems  that: 

•  Is  a  fully  secure,  networked  infrastructure 

•  Provides  high  availability  and  managed  services 

•  Provides  users  a  common  access  methodology  (CAC  -  Common  Access 
Card,  Portals) 

•  Contains  common,  consistent,  accurate,  current  accessible  data  (Shared 
Data  Environment) 

•  Is  available  to  users  through  web  browsers  (web-enabled  or  web-based) 

•  Builds  upon  an  application  layer  (business  logic)  separate  from  the  data 
layer  (database) 

•  Utilizes  Automated  Identification  Technologies  (AIT)  to  support  data  capture 
(Asset  visibility) 

•  Adheres  to  data  and  technical  standards  (DoD,  Dll  COE,  data  standards, 
ANSI,  ISO) 

•  Supports  near  real-time  logistics  C2. 

To  meet  this  objective,  the  approach  to  be  pursued  for  all  technical  activities  will 
consist  of  engineering  studies  and  trade-off  analyses  coupled  with  pilots,  proofs  of 
concept,  and  modeling  and  simulation  activities,  where  applicable.  The  first  step 
will  be  to  translate  the  business  and  higher-level  DoD  GCSS  requirements  into 
specifications  that  are  compatible  with  systems  design  requirements.  Additional 
analysis  will  be  required  to  identify  types  and  quantities  of  business  transactions. 
These  will  be  translated  into  system  stress  and  volume  requirements,  which  will 
impact  server  and  network  requirements.  That,  coupled  with  an  assessment  of 
current  and  planned  architectural  capabilities,  topologies  and  limitations,  will  allow 
for  a  balanced  evaluation  of  various  technical  approaches.  These  activities  are 
clearly  necessary  when  addressing  large-scale  enterprise  systems  and  near  real¬ 
time  sharing  of  data.  These  approaches  will  evolve  into  one,  or  a  combination,  of 
the  following  technical  architectural  solutions: 

•  Development  of  Enterprise  Integration  Portals  or  a  hierarchical  family  of 
portals 

•  Development  of  new,  custom  systems  or  migration  of  legacy  systems  to 
web-based  enterprise  systems 

•  Web-enabling  of  current  systems 

•  Communication  of  data  through  message-oriented  middleware 

•  Integration  of  disparate  databases  into  single  instances  (through  packaged 
or  custom  applications) 

•  Use  of  publish/subscribe  methodologies  using  data  warehousing  or  other 
technologies 

•  Integration  of  Automated  Identification  Technologies  (AIT) 

•  Identification  and  use  of  other  technologies  as  identified  and  appropriate 


83 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  1 


The  systems  and  architectures  developed  will  be  interoperable  through  adherence 
to: 


•  Technical  standards  within  the  Marine  Corps  and  the  portfolio  of  systems 

•  Standardization  of  key  business  data  and  coordination  with  DoD  data 
standardization  programs 

•  Use  of  external  Service  and  Agency  systems,  methodologies  and  tools  as 
appropriate  to  satisfy  Marine  Corps  requirements 

•  Adherence  to  all  relevant  standards 

Critical  to  the  success  of  GCSS-MC  is  the  secure,  network  infrastructure  to  support 
the  network-centric  applications  of  the  future.  This  applies  equally  to  garrison  and 
deployed  operations.  The  GMT  will  work  closely  with  PM  NMCI  and  PM  Radio  to 
ensure  that  requirements  are  effectively  developed  and  described  as  they  impact 
the  network  and  will  work  together  to  engineer  viable  mid  and  long  range  solutions 
for  GCSS-MC. 


11.3.5  GCSS-MC  Process  Summary 


GCSS-MC  Process  Approach 


Planning  Phase  FY01-02 


2001 


Figure  1  GCSS-MC  Process  Approach 


Figure  11.7:  GCSS-MC  Process 
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The  key  to  achieving  GCSS-MC  will  be  the  synchronization  and  alignment  of  the 
many  organizations  and  efforts  ongoing  into  a  cohesive  process  with  a  process 
view.  Only  a  documented  process  can  ensure  that  all  the  steps  in  the  program  are 
addressed  and  coordinated.  The  below  mentioned  four  phases  are  depicted  in 
Figurel  1 .7. 

There  are  four  main  phases  in  the  process: 

1 .  GCSS-MC  feeds,  which  are  the  primary  inputs  to  the  GCSS-MC  process 
such  as  CINC  and  Service  requirements,  revised  business  processes  and 
policies,  and  architecture  considerations. 

2.  Planning,  in  which  all  inputs  are  processed  into  requirements  and  technical 
considerations  and  during  which  the  execution  phase  of  the  project,  is 
planned  in  detail. 

3.  Execution,  during  which  GCSS-MC  is  implemented  and  deployed. 

4.  Operations,  during  which  the  farriily-of-systems  is  employed  and  supported. 

The  phases  will  overlap  each  other  and  the  final  implementation  may  be  versioned 
over  several  years,  however,  the  notional  process  is  basically  unchanged. 

Starting  with 

1.  The  Programs  of  Record  form  a  baseline  of  what  the  USMC  has  today. 
These  systems  will  undergo  the  Systems  Realignment  and  Categorization 
(SRAC)  process.  Many  current  systems  will  be  eliminated  as  a  result  of  this 
analysis.  From  the  remaining  systems  will  be  selected  systems  for  inclusion 
in  the  GCSS-MC  portfolio.  These  systems  will  be  selected  based  on  support 
for  ILC  and  CINC  requirements.  The  portfolio  will  drive  the  gap  analysis  and 
the  alternative  solution  sets. 

2.  The  main  output  will  be  operational  architecture  artifacts.  These  will  formally 
present  requirements  at  a  "business  need"  level  or  lower  level  of  detail  and 
will  be  considered  critical  input. 

3.  These  and  other  DoD  and  commercial  standards  form  the  constraints  for 
constructing  the  technical  and  system  solutions. 

4.  The  Dll/COE  is  the  Defense  Information  Infrastructure  /  Common  Operating 
Environment. 

The  above  4  activities  are  outside,  but  interdependent  of  the  scope  of  the  GMT  in 
GCSS-MC.  These  activities  feed  into  the  Planning  phase  of  GCSS-MC,  which  is  a 
requirements  exploration  and  development  phase,  but  also  includes  all 
management  and  planning  activities  to  prepare  for  the  execution  of  the  GCSS-MC 
project. 
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The  To-be  OA  and  the  GCSS  CRD  are  the  primary  inputs  to  the  Requirements 
process 

5.  This  major  process  involves  developing  system  requirements  and 
specifications  in  the  functional  domains  and  identifying  gaps  in  the  current 
capabilities  to  meet  those  requirements.  Many  requirements  will  be 
discovered  or  validated  during  the  many  pilot  and  proof  of  concept  programs 
that  are  currently  ongoing 

6.  These  activities  are  independent  and  largely  uncoordinated,  however,  they 
will  be  integrated  into  the  GCSS-MC  process  as  they  are  discovered  and 
appraised  for  adding  value  to  the  program.  Other  requirements  will  be 
discovered  through  concept  and  trade  studies,  such  as  capabilities  that  are 
available  in  commercial  software  packages. 

7.  The  Operational  Architecture  Technical  Assessment  7  will  determine  the 
technical  capability  and  gaps  of  the  current  and  projected  architectures  to 
support  the  functional  and  technical  requirements  for  GCSS-MC.  The 
results  of  this  activity  will  be  integrated  with  all  discovered  requirements  and 
used  as  input  to  the  alternatives  analysis. 

8.  The  Data  Standardization  effort  8  will  perform  the  logical  data  modeling  to 
ensure  that  GCSS-MC  is  easily  interoperable  and  oriented  towards  a  shared, 
integrated  data  environment.  This  effort  works  concurrently  with  the 
development  of  data  requirements  in  process  5  and  feeds  into  the 
requirements  integration  and  solutions  analysis  activity  9. 

9.  While  activity  5  is  oriented  towards  capturing  requirements,  the 
requirements  integration  activity  9  is  oriented  towards  integrating  them  and 
developing  the  specifications  for  moving  forward  and  assessing  solutions 
applicable  to  the  problem  domains.  In  this  phase,  all  requirements  are 
brought  together  and  solution  alternatives  are  investigated.  The  result  is  a 
body  of  knowledge  sufficient  to  develop  detailed  plans,  estimates  and  costs 
for  specific  systems  and  technical  solutions  to  be  implemented  in  the 
Execution  Phase.  This  activity  will  include  additional  studies  and  analysis  to 
present  alternatives  and  make  decisions  about  the  future.  These  studies  will 
include  business  case  assessments  to  weigh  project  phasing  and  trade-offs 
on  return  on  investment  between  make  or  buy  solutions.  It  is  expected  that 
there  will  be  overlap  between  planning  and  execution,  as  some  capabilities 
will  be  implemented  later  than  other  higher  priority  functions. 

10.  From  solutions  analysis,  GCSS-MC  moves  into  the  execution  phase  where 
the  solutions  are  implemented.  There  will  be  a  combination  of  five  types  of 
solutions:  make  10,  where  new  systems  are  custom  built  to  achieve  desired 
capabilities; 
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11.  By  11,  where  commercial  packages  or  tools  are  purchased  to  leverage 
commercial  capabilities  into  the  Marine  Corps; 

12.  Enhance  12,  where  existing  programs  of  record  are  re-engineered  or 
otherwise  enhanced  to  leverage  existing  capabilities; 

13.  Information  technology  infrastructure  13,  where  IT  solutions  are  designed 
and  built  to  support  the  required  services;  and  legacy  systems  integration 
and 

14.  Data-warehousing  applications  14  are  constructed  to  provide  a  platform  for 
a  shared  data  environment.  As  these  solutions  are  being  implemented, 
existing  and  proven  pilots  and  other 

15.  Prototypes  15  may  be  integrated  into  the  solution  sets  as  an  additional 
alternative.  Like  the  pilots  in  activity  6,  they  will  be  taken  as  targets  of 
opportunity  for  adding  value. 

16.  As  the  approach  of  GCSS-MC  is  a  "bottoms-up"  approach,  each  solution 
will  be  implemented  as  a  separate  project  16  with  a  project  manager/officer 
overseeing  the  specific  activity. 

17.  These  individual  efforts  will  be  coordinated  and  supported  centrally  by  the 
GMT  acting  as  a  Project  Management  Office  operating  with  authority  from 
the  Program  Manager.  As  the  projects  are  completed,  they  will  be  integrated 
into  the  overall  implemented  solution. 

18.  They  will  be  deployed  in  a  phased  manner  17. 

19.  The  support  activity  18  will  be  growing  as  more  functions  and  capabilities 
are  implemented  within  GCSS-MC.  The  core  infrastructure  will  be  built  as 
one  of  the  first  projects  to  be  implemented  in  19. 

20.  The  support  activity  includes  operations  and  application  support  and 
maintenance  as  well  as  an  enterprise  helps  desk  function. 

As  it  operates,  GCSS-MC,  as  the  physical  implementation  of  the  ILC,  will 
support  both  logistics  real-time  operations  19  and  GCSS  20. 


1 1 .3.6  Summary  on  Autonomic  Logistics 

Autonomic  Logistics  (AL)  is  a  concept  which  is  supposed  to  follow  the  following 
facts:  using  advanced  IT  systems  to  support  military  command  structure  with  real 
or  near-real  time  information  on  the  status  of  weapons  and  support  systems 
deployed  to  the  battle  space  or  other  area  of  operations. 
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The  main  motivation  is:  currently  mission  critical  data  on  weapon  and  support 
systems  is  communicated  from  the  battlefield  through  manual  methods,  which 
causes:  Reporting  burden  on  the  commander;  Data  is  generally  inaccurate  and/or 
lacks  granularity;  Not  timely  -  up  to  24  hours  old;  And  because  of  these  information 
delay,  the  current  logistic  system  is  inefficient  with  respect  to  inventory  utilization, 
readiness  rate,  etc.  But  AL  is  expected  to  overcome  these  shortcomings  and  bring 
reduced  spares  inventories,  higher  readiness  rates  and  overall  reduced  logistics 
footprint. 

Based  on  the  study  of  current  weapon  and  support  system  and  experience  from 
available  military  AL  applications  such  as  Joint  Strike  Fighter  (JSF)  AutoLog,  and 
future  weapon  and  support  system  will  operate  in  AL  environment  that  should  have 
the  following  key  system  components: 

1.  Ground  Equipment  which  encompasses  both  diagnostic  and  prognostic 
capability  supported  by  Health  Management  system  aboard; 

2.  Technically  supporting  and  operational  personnel; 

3.  An  advanced  Information  System  characterized  with  Wireless  communication 
technology  and  Integrated  Data  Environment  (IDE)  and  Shared  Data 
Environment  (SDE); 

4.  A  logistic  infrastructure  that  will  be  responsive  to  support  requirements. 

Currently,  there  are  similar  systems  or  concept  existing  in  both  military  and 
commercial  field.  In  military  field,  there  are:  COMTECH  Mobile  Datacom,  U.S. 
army  Advanced  Diagnostics  Improvement  Program,  PLRS,  JSF  Autonomic 
Logistics,  Weapon  System  Support  Platform  Based  Readiness,  etc.  In  commercial 
field,  there  are:  OmniTRACS,  ONSTAR  and  Low  jack.  Doing  research  in  these 
similar  systems  or  concept  may  help  us  to  have  clearer  picture  about  AL  in  our 
framework. 
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11.4  Appendix:  2  -  URLs  for  Condition  based  maintenance 

The  following  websites  give  detailed  information  on  different  aspects  of  CBM,  from 
Commercial  DoD  and  Research  Views. 


Accurate  Automation 
Corporation 

http://www.accurate-automation.com/ 

Adaptics,  Inc. 

htto://adaptics.com/ 

Alexis  Logic  Corporation 

http://www.  alexis.com/alc.html 

ALPHATECH,  Inc. 

http://www.alphatech.com/ 

Augusta  Technology 

http://www.auqusta.co.uk/aboutauq.htm 

BEASY 

http://www.beasv.com/ 

BPC  International  Inc. 

http://www.tfa2.com/bpc/ 

BRETECH  ENGINEERING 

LTD 

http://www.bretech.com/ 

C  &  S  Group  Pty.  Ltd. 

http://interdomain.net.au/~csqroup/ 

Cadick  Corporation 

http://www.electricnet.com/cadick/cndbased.htm 

China  Steel  Corporation 

http://www.csc.com.tw/ 

Computational  Systems  Inc. 

http://www.comosvs.com/ 

CranePartner  International 

http://www.cranepartner.com/ 

Danaos  Maritime  Services 

http://193.92.153. 1/ 

Dingo  Maintenance  Systems 

http://www.rollanet.orq/~dinqo/ 

DLI  Engineering  Corporation 

http://www.DLIenqinerrinq.com/ 

Dofasco  Inc. 

http://www.dofasco.ca/ 

Dyal  Associates 

http://www.fc.net/~dval/ 

DYNAMIC  INSTRUMENTS 

http://www.dynamicinst.com/ 
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Electricity  Generation  Authority 

of  Thailand  http://www.eqat.or.th/ 


Engineering  Mechanics 
Technology,  Inc. 

http://www.emtinc.com/ 

Entek  IRD  International 
Corporation 

http://www.entek.com/ 

Environment  One  Corporation 

http://www.eone.com/eone/ 

Equitronics 

http://www.equitronics.com/ 

ERA  Technology  Ltd. 

http://www.era.co.uk/ 

EXSYS,  Inc. 

http://www.exsvsinfo.com/ 

Failure  Analysis  Associates, 

Inc. 

http://www.fail.com/ 

Field  Diagnostic  Services,  Inc. 

http://www.ies.laf.in.us/acrx/ 

GasTOPS,  Ltd. 

http://www.qastops.com/ 

GDE  Systems,  Inc. 

http://www.qdesvstems.com/ 

Gensym  Corporation 

http://www.qensvm.com/ 

Geotest,  Inc. 

http://www.qeotestinc.com/ 

Hardy  Instruments 

http://www.hardyinst.com/index.html 

Hartford  Steam  Boiler 

http://www.hsb.com/ 

Hathaway  Power 

Instrumentation 

http://www.hathawav-svstems.com/ 

Honeywell  Technology  Center 

http://www.htc.honeywell.com/ 

IDAX  Incorporated 

http://www.idax.com/ 

Innovative  Software  Designs 

http://www.innovsw.com/ 

Inteltech  Enterprises,  Inc 

http://www.inteltek.com/ 

International  Submarine 

http://www.ise.bc.ca/ 
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Engineering,  Ltd. 

IVO  Transmission  Services  Ltd. 
(IVS) 

htto://www.ivo.fi/ivswww/e  home.htm 

KAUKO  Condition  Monitoring 
Ltd. 

htto://kaukomarkkinat.fi/kcm/ 

KETRON  Division,  The 

Bionetics  Corporation 

http://www.  ketron.com 

Knowledge  Industries 

http://www.kic.com/ 

LG  Group 

http://www.lq.co.kr/ 

Liberty  Technologies 

http://www.libertvtech.com/ 

Life  Cycle  Engineering,  Inc. 
(LCE) 

http://www.lce.com/ 

Machinery  Condition 

Monitoring  Inc. 

http://www.hiqhres.nb.ca/mcminc/index.htrnl 

MacNeal-Schwendler 

Corporation 

http://www.macsch.com/ 

Maintenance  and  Diagnostics, 

LLC 

http://www.tncnet.com/-MandD/ 

MARINTEK 

http://mt1  .marintek.sintef.no/ 

Material  Integrity  Solutions,  Inc. 

http://www.misolution.com/ 

Monition  Ltd.  (International) 

http://www.monition.com/ 

National  Instruments 

http://www.natinst.com/ 

Novadyne 

http://www.ncsi.com/ 

PdMA  Corporation 

http://www.pdma.com/ 

Powertech  Labs  Inc. 

http://web.ucs.ubc.ca/bchvdro/powertech/default 

.html 

Predictive  Maintenance 

http://iquest.com/~pmi/ 
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Inspection,  Inc. 

PRUFTECHNIK  AG 

http://www.Druftechnik.com/ 

PSDI 

http://www.psdi.com/ 

Randle,  Inc. 

http://www.cauest.com/chaos.html 

Reliability  Center,  Inc. 

http://www.reliabilitv.com/ 

Revere 

http://www.revereinc.com/ 

Rockwell  International 

http://www.rockwell.com/ 

Sargent  Controls  &  Aerospace 

http://www.sarqentcontrols.com/ 

SKF  Condition  Monitoring 

http://www.skfcm.com/ 

SKM  Systems  Analysis,  Inc. 

http://www.skm.com/afault.html 

Solartron  Instruments 

http://www.solartron.com/index.htm 

Tracor  Applied  Sciences,  Inc. 

http://www.aard.tracor.com/home/ 

Triant  Technologies  Inc. 

http://www.triant.com/ 

TSW  International,  Inc 

http://www.tswi.com/index.html 

UE  systems,  Inc. 

http://www.uesvstems.com/ 

Vetronix  Corporation 

http://www.vetronix.com/ 

Vibrant  Technology,  Inc 

http://www.vibetech.com/ 

Vibration  Measurement 
Technology  Ltd. 

http://www.isp.fi/vmt/vmt2945.htm 

Vibration  Specialty  Corporation 

http://www.iliad.com/vib/default.html 

VibroAcoustical  Systems  and 
Technologies,  Inc 

http://www.inteltek.com/ 
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1 1 .5  Appendix:  3  -  Autonomic  Logistics  (AL)  on  Joint  Strike 
Fighter  (JSF) 


11.5.1  Overview  on  JSF  AL 

The  JSF  AL  is  a  new  system  that  will  enable  the  aircraft  to  function  throughout  the 
life  of  the  platform  with  low  costs  when  compared  with  the  legacy  systems.  AL  is  a 
concept,  which  will  automate  the  aircraft  logistics  with  very  less  human  intervention. 
JSF  actions  that  will  support  this  concept  include  maintenance  scheduling,  flight 
scheduling,  order  spare  parts  etc. 

AL  encompasses  four  key  features  to  provide  a  comprehensive  logistics  support 
for  the  JSF  and  they  are  as  follows: 

1.  Prognostics  and  Health  Management  (PHM) 

2.  Joint  Distributed  Information  System  (JDIS) 

3.  Technologically  Enabled  Maintainer 

4.  Advanced  Logistics  Infrastructure 

JSF  Prognostics  and  Health  Management  concept  is  the  corner  stone  of 
Autonomic  Logistics.  The  PHM  provides  data  information  and  the  knowledge  for 
initiating  the  Autolog  chain. 

The  below  mentioned  are  the  capabilities  of  the  PHM: 

1 .  Enhance  flight  safety 

2.  Improve  efficiency  of  the  logistics  chain 

3.  Allow  scheduling  of  logistics  events  to  compliment  operational  planning 

The  proposed  architecture  for  the  PHM  includes  a  hierarchical  approach.  In  brief, 
the  PHM  begins  by  collecting  the  data  at  the  sensor  level  and  transmits  it  to  the 
area  reasoners,  who  will  turn  this  data  into  information  for  a  specific  subsystem. 
This  system,  by  design  is  envisioned  to  provide  valuable  information  and  an 
intelligent  warfighter. 

The  key  aspect  of  the  PHM  is  the  usage  of  minimum  number  of  specialized 
sensors  used  as  area  managers.  By  definition,  area  managers  contains  software 
reasoners  or  software  modules  in  which  data  from  various  sources  is  fused 
together  by  means  of  fuzzy  logic,  neural  networks,  data  fusion,  model  and  case 
based  reasoning,  trends  to  detect  faulty  parts  and  anomalies. 

The  concept  behind  the  PHM  is  not  to  overload  the  warfighter  with  a  large  number 
of  sensors,  which  tend  to  fail  and  also  induce  ambiguity  when  detecting  part 
failures. 
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Each  area  manager  monitors  a  particular  subsystem  of  the  warfighter  i.e.  area 
managers  for  propulsion,  structures,  vehicle  management  system  and  mission 
systems.  With  its  own  software  algorithms  and  computing  capabilities,  the  area 
manager  analyzes  the  signals  automatically  from  the  sensors  and  other  data 
sources  to  determine  whether  the  part  or  a  component  of  a  specific  subsystem 
exhibits  characteristic  that  may  lead  to  failure.  Information  collected  by  the  area 
managers  is  then  transmitted  to  a  single  air  vehicle  manager  for  further  information 
fusion  and  elimination  of  ambiguities.  The  single  air  vehicle  manager  later  filters 
information  and  sends  certain  information  to  the  pilot  for  his  use  and  the  rest  is 
conveyed  to  the  maintenance  personnel  for  his  action. 

The  significance  of  the  JSF  software  architecture  is  to  minimize  ambiguities  and  its 
purpose  is  as  follows: 

1.  It  allows  the  diagnostic  system  to  perform  more  functions  without  the 
introduction  of  abundant  number  of  specialized  sensors.  It  is  the  job  of  the 
software  architecture  to  convert  this  data  into  actual  information  for 
maintenance. 

2.  By  fusing  data  from  various  sources,  anomalies  can  be  crosschecked  with 
information  from  other  subsystems  in  order  to  avoid  false  alarms.  All  sensor 
information  will  be  validated  in  the  area  and  single  air  vehicle  manager  level 
with  other  sensor  data  or  aircraft  parameters  to  verify  the  fault. 

Data  filtering  is  accomplished  by  employing  a  new  technology  called  “coherence 
analysis”  that  detects  components  performance  anomalies. 

Another  aspect  of  the  PHM  is  to  perform  many  of  the  prognostic  calculations, 
remaining  useful  life  calculations,  cycle  counting,  and  lifeing  of  components.  This 
processed  information  together  with  the  rest  of  the  information  from  the  single  air 
vehicle  is  transmitted  to  the  JDIS  to  inform  the  supply  chain  what  it  has  to  do  to 
maintain  the  airplane  fully  operational.  The  metric  to  be  used  is  probability  of 
failure  within  a  specified  number  of  flight  hours.  The  aim  of  the  JSF  prognostics 
system  is  to  have  an  estimate  of  remaining  useful  life  of  a  component  in  a 
warfighter  at  any  given  time.  Prognostics  will  also  allow  a  lead-time  for  the 
logistics  pipeline  to  get  parts  and  to  educate  the  maintainers  to  change  those  parts. 

Another  significant  aspect  of  Autonomic  Logistics  is  “part  tracking”.  With  AL,  all 
component  parts  will  be  tracked  by  serial  number  across  all  aircraft  tail  numbers. 
For  example,  if  a  set  of  new  bearings  were  not  performing  up  to  its  standard,  then 
JDIS  would  be  able  to  identify  all  bearings  from  the  given  shipment  and  their 
locations  and  pull  them  before  the  start  to  fail  while  in  operation.  This  will  avoid  in 
ground  the  entire  fleet  in  order  to  check  all  bearing  on  all  aircraft  to  identify  the 
faulty  ones. 
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Affordable,  Survivabte,  Maintainable,  Supportable 


Figure  11.8:  Features  of  JSF  AL 


Joint  Distributed  Information  Systems  (JDIS): 

The  “backbone"  of  AL  is  JDIS  and  will  provide  distributed  information  system  to 
integrate  PHM  supplied  data  and  information  to  all  the  other  necessary 
maintenance  management,  logistics,  supply,  OEM,  mission  planning  etc.  JDIS 
provides  the  passage  that  would  take  the  prognostic  and  diagnostic  information 
transmitted  by  the  aircraft  and  determines  from  it  the  manpower  numbers, 
capabilities  and  training  requirements  to  complete  the  necessary  tasks.  Some  of 
the  tasks  that  will  be  performed  either  automatically  or  integrated  with  JDIS  are  as 
follows: 

=>  Mission  planning 

=>  Maintenance  action  scheduling 

=5-  Ordering  of  spare  parts 

=>  Scheduling  of  flight  and  maintenance  training 

=>  Assignment  of  specific  plots  to  specific  missions  based  upon  experience 
and  readiness 

=>  Assigning  specific  aircraft  to  specific  missions  based  upon  aircraft 
availability  and  capability 

=>  Storing  maintenance,  training,  spare  part,  and  logistic  information  in  the 
database  warehouse 

It  has  to  be  noted  that  all  these  tasks  are  performed  automatically;  at  any  given 
time,  a  person  with  the  necessary  authority  can  access  the  system  and  make 
changes  as  required. 

The  information  fusion  capability  of  the  PHM  system  will  allow  JDIS  to  output  and 
pass  on  actions  and  recommendations  rather  than  just  data.  These  support 
decision  tools  will  include:  maintenance  information,  supply  chain  management, 
health  and  usage  information,  training  management,  and  recommendations 
regarding  best  use  of  resources. 
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Technologically  Enabled  Maintainer 

The  maintainer  in  the  AL  concept  has  the  full  set  of  modern,  technologically 
capable  and  appropriate  tools  to  act  efficiently  and  promptly  when  called  for 
immediate  maintenance  duty.  The  tool  sets  include:  comprehensive  knowledge  of 
the  actual  aircraft  health  before  beginning  work  (PHM  and  JDIS),  appropriate  and 
timely  training  to  conduct  the  task  (prognostics  lead  time,  prior  training  methods), 
and  interactive  guidance  available  in  real  time  to  provide  supplementary 
information  when  required. 

It  is  important  to  note  that  the  logistics  and  PHM  should  have  minimal  human 
intervention. 

Due  to  its  autonomic  nature,  the  tasks  assigned  to  the  maintainer  should  be 
transparent  and  must  be  presented  in  the  manner  that  provides  proper  procedures, 
safety,  detail  appropriate  to  skill  level,  rehearsal/review  of  the  task  when  requested, 
tools  and  parts  required  and  quality  and  assurance. 

Advanced  Logistics  Infrastructure 

The  information  obtained  from  PHM  and  JDIS  are  of  no  avail  if  the  logistics 
infrastructure  is  not  flexible  and  responsive  enough  to  generate  the  necessary 
support  in  the  right  place  when  required.  Some  of  the  issues  to  be  tackled  to  have 
the  appropriate  infrastructure  are  the  levels  of  maintenance,  Inventory  Policies, 
and  supply  chain  management. 
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11.6  Appendix:  4  -  Sensor  Processing 
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11.6.1  Sensors 

11.6.1.1  Transducers 

Sensors  and  actuators  can  both  be  transducers.  A  transducer  is  a  device  that 
converts  input  energy  of  one  form  into  output  energy  of  another  form.  For  example, 
a  microphone  is  a  sensor  that  converts  sound  energy  (in  the  form  of  pressure)  into 
electrical  energy,  while  a  loudspeaker  is  an  actuator  that  converts  electrical  energy 
into  sound  energy. 


1 1.6. 1.2  Classical  Integrated  Sensor 

A  Sensor  is  a  device,  which  is  designed  to  acquire  information  from  an  object  and 
transform  it  into  an  electrical  signal.  A  classical  integrated  sensor  can  be  divided 
into  four  parts  as  shown  in  Figure  1 1 .9. 

Figure  11.9  shows  the  notion  of  classical  integrated  sensors.  The  first  block  is 
sensing  element  (for  example,  resistor,  capacitor,  transistor,  piezo-electric  material, 
photodiode,  resistive  bridge,  etc).  The  signal  produced  from  the  sensing  element 
itself  is  often  influenced  by  noise  or  interference.  Therefore,  signal-conditioning 
and  signal-processing  techniques  such  as  amplification,  linearization, 
compensation  and  filtering  are  necessary  (second  block)  to  reduce  sensor  non¬ 
idealities. 

In  case  of  data  acquisition,  the  signal  from  the  sensor  must  be  in  a  serial  or  parallel 
digital  format.  This  function  can  be  realized  by  the  analog-to-digital  or  frequency-to- 
digital  converter.  The  last  block  is  a  sensor-bus  interface  [2]. 


Figure  11.9:  Classical  integrated  sensors 


11.6.1.3  Smart  Sensor 

A  Smart  sensor  block  diagram  is  shown  in  Figure  11.10.  A  microcontroller  (pK)  is 
typically  used  for  digital  signal  processing  (for  example,  digital  filtering),  analog-to- 
digital  or  frequency-to-code  conversions,  calculations  and  interfacing  functions. 


99 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  1 


Microcontrollers  can  be  combined  or  equipped  with  standard  interface  circuits. 
Many  microcontrollers  include  the  two-wire  l2C  bus  interface,  which  is  suited  for 
communication  over  short  distances  (several  metres)  or  the  serial  interface  RS- 
232/485  for  communication  over  relatively  long  distances. 

However,  the  essential  difference  of  the  smart  sensor  from  the  integrated  sensor 
with  embedded  data-processing  circuitry  is  its  intelligence  capabilities  (self¬ 
diagnostics,  self-identification  or  self-adaptation  (decision  making))  functions.  As  a 
rule,  these  functions  are  implemented  due  to  a  built-in  microcontroler 
(microcontroller  core  (‘microcontroller  like’  ASCI)  or  application-specific  instruction 
processor  (ASIP))  or  DSP.  New  functions  and  the  potential  to  modify  its 
performance  are  the  main  advantages  of  smart  sensors.  Due  to  smart  sensor 
adaptability  the  measuring  process  can  be  optimized  for  maximum  accuracy, 
speed  and  power  consumption.  Sometimes  ‘smart  sensors’  are  called  ‘intelligent 
transducers’  [2], 


Figure  11.10:  Smart  sensor 


11.6.1.4  Sensors 

A  sensor  converts  the  physical  phenomena  of  interest  into  a  signal  that  is  input  into 
your  data  acquisition  hardware.  There  are  two  main  types  of  sensors  based  on  the 
output  they  produce:  digital  sensors  and  analog  sensors. 

Digital  sensors  produce  an  output  signal  that  is  a  digital  representation  of  the  input 
signal,  and  has  discrete  values  of  magnitude  measured  at  discrete  points  in  time.  A 
digital  sensor  must  output  logic  levels  that  are  compatible  with  the  digital  receiver. 
Some  standard  logic  levels  include  transistor-transistor  logic  (TTL)  and  emitter- 
coupled  logic  (ECL).  Examples  of  digital  sensors  include  switches  and  position 
encoders. 

Analog  sensors  produce  an  output  signal  that  is  directly  proportional  to  the  input 
signal,  and  is  continuous  in  both  magnitude  and  in  time.  Most  physical  variables 
such  as  temperature,  pressure,  and  acceleration  are  continuous  in  nature  and  are 
readily  measured  with  an  analog  sensor.  For  example,  the  temperature  of  an 
automobile  cooling  system  and  the  acceleration  produced  by  a  child  on  a  swing  all 
vary  continuously. 
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The  sensor  you  use  depends  on  the  phenomena  you  are  measuring.  Some 
common  analog  sensors  and  the  physical  variables  they  measure  are  listed  below. 


Common  Analog  Sensors 

Sensor 

Physical  Variable 

Accelerometer 

Acceleration 

Microphone 

Pressure 

Pressure  gauge 

Pressure 

Resistance  temperature  device  (RTD) 

Temperature 

Strain  gauge 

Force 

Thermocouple 

Temperature 

Table  11.1:  Common  Sensors  and  physical  variables 


11.6.2  Signal  Conditioning 

Sensor  signals  are  often  incompatible  with  data  acquisition  hardware.  To 
overcome  this  incompatibility,  the  sensor  signal  must  be  conditioned.  The  type  of 
signal  conditioning  required  depends  on  the  sensor  you  are  using  [1].  For  example, 
a  signal  might  have  a  small  amplitude  and  require  amplification,  or  it  might  contain 
unwanted  frequency  components  and  require  filtering.  Common  ways  to  condition 
signals  include 

•  Amplification 

•  Filtering 

•  Electrical  isolation 

•  Multiplexing 

•  Excitation  Source 
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Figure  11.11:  Overall  scheme  of  signal  conditioning 


1 1. 6. 2. 1  Amplification 

Because  real-world  signals  are  often  very  small  in  magnitude,  signal  conditioning 
can  improve  the  accuracy  of  data.  Amplifiers  boost  the  level  of  the  input  signal  to 
better  match  the  range  of  the  analog-to-digital  converter  (ADC),  thus  increasing  the 
resolution  and  sensitivity  of  the  measurement.  While  many  Data  Acquisition 
devices  include  onboard  amplifiers  for  this  reason,  many  transducers,  such  a 
thermocouples,  require  additional  amplification. 


11.6.2.2  Attenuation 

Attenuation  is  the  opposite  of  amplification.  It  is  necessary  when  the  voltages  to  be 
digitized  are  beyond  the  input  range  of  the  digitizer.  This  form  of  signal  conditioning 
diminishes  the  amplitude  of  the  input  signal  so  that  the  conditioned  signal  is  within 
range  of  the  ADC.  Attenuation  is  necessary  for  measuring  high  voltages. 


11.6.2.3  Filtering 

Filtering  removes  unwanted  noise  from  the  signal  of  interest.  Additionally,  signal 
conditioners  can  include  filters  to  reject  unwanted  noise  within  a  certain  frequency 
range.  Almost  all  DAQ  applications  are  subject  to  some  level  of  50  or  60  Hz  noise 
picked  up  from  power  lines  or  machinery.  Therefore,  most  conditioners  include 
lowpass  filters  designed  specifically  to  provide  maximum  rejection  of  50  to  60Hz 
noise. 
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Figure  11.12:  Filtering 


11.6.2.4  Electrical  Isolation 

If  the  signal  of  interest  contains  high-voltage  transients  that  could  damage  the 
computer,  then  the  sensor  signals  should  be  electrically  isolated  from  the  computer 
for  safety  purposes. 

Improper  grounding  of  the  system  is  one  of  the  most  common  causes  for 
measurement  problems,  including  noise  and  damaged  measurement  devices. 
Signal  conditioners  with  isolation  can  prevent  most  of  these  problems. 


11.6.2.5  Multiplexing 

A  common  technique  for  measuring  several  signals  with  a  single  measuring  device 
is  multiplexing.  Typically,  the  digitizer  is  the  most  expensive  part  of  a  data 
acquisition  system.  By  multiplexing,  you  can  sequentially  route  a  number  of  signals 
into  a  single  digitizer,  thus  achieving  a  cost-effective  way  to  greatly  expand  the 
signal  count  of  your  system.  Multiplexing  is  necessary  for  any  high-channel-count 
application. 


11.6.2.6  Excitation  Source 

Some  sensors  require  an  excitation  source  to  operate.  For  example,  strain  gauges, 
and  resistive  temperature  devices  (RTDs)  require  external  voltage  or  current 
excitation.  Signal  conditioning  modules  for  these  sensors  usually  provide  the 
necessary  excitation.  RTD  measurements  are  usually  made  with  a  current  source 
that  converts  the  variation  in  resistance  to  a  measurable  voltage. 

As  show  in  Figure  11.13,  there  is  the  process  of  intelligent  diagnosis  and  prognosis 
system  [5], 
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11.6.3  Signal  Processing 
11.6.3.1  Signals 

Signals  commonly  need  to  be  processed  in  a  variety  of  ways.  For  example,  the 
output  signal  from  a  transducer  may  well  be  contaminated  with  unwanted  electrical 
"noise".  The  signal  is  often  strongly  affected  by  "mains  pickup"  due  to  electrical 
interference  from  the  mains  supply.  Processing  the  signal  using  a  filter  circuit  can 
remove  or  at  least  reduce  the  unwanted  part  of  the  signal.  Increasingly  nowadays 
the  filtering  of  signals  to  improve  signal  quality  or  to  extract  important  information  is 
done  by  DSP  techniques  rather  than  by  analog  electronics. 


1 1. 6.3.2  Digital  Signal  Processing 

According  to  Texas  Instruments  digital  signal  processing  is  defined  as  1  The 
science  concerned  with  representation  of  signals  by  sequences  of  numbers  and 
the  subsequent  processing  of  these  number  sequence'.  Processing  involves  either 
extracting  certain  parameters  from  a  signal  or  transforming  it  into  a  form  that  is 
more  applicable.  The  digital  implementation  of  signal  processing  has  several 
advantages: 

•  It  is  possible  to  accomplish  many  tasks  inexpensively  that  would  be  either 
difficult  or  impossible  in  the  analog  domain,  for  example,  Fourier  transforms. 

•  Digital  systems  are  insensitive  to  environmental  changes  and  component 
tolerances  and  ensure  predictability  and  repeatability. 

•  Reprogrammability  features. 
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Figure  11.13:  Schematic  Diagram  of  Intelligent  Diagnosis  and  Prognosis 

System 


11.6.4  Vehicle  Fault  Diagnostic 

Fault  Diagnosis  can  be  generally  defined  as  the  process  that  identifies  the  root 
cause  of  a  failure.  Vehicle  level  fault  diagnostic  should  be  considered  an  important 
area  of  study  for  several  reasons,  including  the  following: 

•  Failure  diagnosis  adds  directly  to  the  cost  of  vehicle  parts  -  software  is  not 
“free"  and  warranty  part  returns  cost  money. 

•  Failure  diagnosis  is  a  large  contributor  to  the  labor  time  involved  in  vehicle 
servicing  -  once  a  problem  is  identified,  a  solution  is  typically  swift. 

•  Improper  fault  diagnosis  can  lead  to  an  incorrect  repair  action  -  this  leads  to 
opportunity  costs  and  fosters  the  perpetuation  of  inefficient  problem  solving 
(unsatisfied  customers  tend  not  to  return) 

There  are  several  levels  of  vehicle  diagnostics.  The  first  level  of  diagnostics  may 
be  a  simple  reminder  to  the  driver  that  standard  maintenance  (i.e. ,  replacing  filters 
and  fluids)  is  required.  The  next  level  of  diagnostics  is  targeted  for  the  service 
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technician,  using  more  sophisticated  tools  and  techniques.  And,  there  is  a  level  or 
levels  of  tools  and  methods  used  by  the  system  architects  and  engineers  who 
develop  the  sub-system  hardware  and  software.  A  well-planned  diagnostic  strategy 
fully  comprehends  the  relationships  between  these  levels  [3]. 


1 1 .6.5  Sensor  Fusion 

In  the  case  of  multiple  sensor  faults,  highly  interactive  components  or  subsystems, 
information  from  a  single  sensor  does  not  provide  enough  intelligence  to  accurately 
diagnose  all  of  the  possible  faults.  A  better  approach  is  to  exploit  the  use  of 
multiple  sensors  to  provide  additional  information  to  the  diagnostic  algorithm.  Using 
the  approach,  observers  can  be  selected  such  that  they  provide  complementary 
and/or  redundant  information  about  the  component  or  subsystem  behavior.  The 
additional  information  provided  by  this  scheme  can  be  used  to  broaden  the  number 
and  scope  of  potential  faults  that  the  diagnostic  algorithm  detects  and  reduces  the 
probability  of  misdiagnosing  a  failure. 

Fusing  two  raw  signals  together  and  processing  the  resulting  information,  improved 
characterization  of  the  input  signals  can  be  obtained.  Further,  by  combining  a 
number  of  fused  input  signals  with  a  simple  voting  or  decision  making  algorithm, 
improvements  in  fault  classification  accuracy  can  also  be  obtained  [3], 


11.6.6  LAV  Diagnostic 

11.6.6.1  LAV  Condition  Monitoring  Defined 

LAV  Condition  Monitoring  (LCM)  systems  that  we’ll  discuss  in  this  project  refer  to 
computer-based  tools  for  maintenance  and  process  control  related  to  industrial 
machinery.  Such  setups  can  assist  with: 

•  Repair  /  Rebuild  Decisions 

•  Process  Control  and  Optimization 

One-way  of  classifying  LCM  systems  are  as  either  continuous  or  periodic,  based 
on  when  and  how  monitoring  is  performed.  Continuous  monitoring  systems  are 
commonly  attached  to  the  machine  of  interest.  Periodic  monitoring  systems  are 
often  portable  and  are  used  on  multiple  machines.  Although  well  focus  on 
continuous  monitoring  in  this  project,  much  of  the  information  will  also  apply  to 
periodic  monitoring  [1], 


11.6.6.2  LCM  System  Elements 

A  good  place  to  start  is  with  an  overview  of  the  components  of  a  LAV  conditioning 
monitoring  system.  These  include: 
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Figure  11.14:  LCM  Components 

•  The  first  component  is  the  LAV  that  you  intend  to  monitor. 

•  Transducers  such  as  accelerometers,  proximity  probes,  and  thermocouples 
convert  machine-generated  signals  such  as  sound,  vibration,  temperature, 
pressure,  power  consumption  and  others  into  a  measurable  voltage. 

•  Cabling  and  perhaps  signal  conditioning  hardware  connect  your  transducers 
to  a  measurement  instrument. 

•  The  measurement  instrument  here  is  a  standard  PC.  As  we’ll  see,  this  offers 
a  number  of  benefits. 

•  Installed  hardware  and  software  converts  the  PC  into  a  measurement 
instrument. 

•  Acquisition  hardware  in  the  form  of  plug-in  PCI  or  CompactPCI/PXI  card  or 
cards  can  provide  signal  conditioning  and  converts  the  sensor  output  to  a 
computer-friendly  form. 

•  Software  for  measurement  and  automation  controls  our  acquisition 
hardware,  provides  a  monitor-site  man/machine  interface  (MMI),  and 
interprets  acquired  signals  for  monitoring  and  to  assist  diagnosis.  It  can  also 
provide  functions  such  as  signal  interpretation,  report  generation,  and  data 
sharing  using  wireless. 
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11.6.6.3  LCM-Relevant  Information 

In  planning  a  custom  machine  condition  monitoring  system,  it’s  useful  to  consider 
some  of  the  potential  sources  of  information  that  could  be  monitored.  LCM-related 
information  can  be  either: 

•  Fixed  /  known  (machine  design,  machine  health  history) 

•  Vary  with  time  (operating  environment,  operating  conditions,  operating 
parameters,  and  machine  health) 

The  acquisition  portion  of  LCM  system  will  focus  on  the  varying  information. 
Measurable:  temperature,  pressure,  vibration,  power,  flow,  and  many  others. 
Acquiring  signals  such  as  temperature,  pressure,  vibration,  power,  flow,  and 
perhaps  others  is  only  the  first  step;  effective  monitoring  systems  rely  on  an 
association  of  available  information  with  the  machine  characteristics  of  interest. 
The  analysis  portion  of  LCM  system  will  process  measured  data  and  analyze  it  in 
conjunction  with  other  known  information  such  as  machine  design  and  machine 
health  history. 

For  information  to  be  useful  for  monitoring,  it  must  be  related  to  an  excitation 
source  on  your  machine.  It’s  the  job  of  measurement-oriented  analysis  to  relate 
measurements  to  excitation  sources  due  to  LAV  operation.  Doing  so  is  important 
because: 

•  Measurable  responses  are  indirect  indicators  of  LAV’s  response  to 
excitation 

•  Excitation  is  a  function  of  the  LAV's  operating  environment  and  operating 
parameters 

•  A  LAV’s  response  to  excitation  is  a  function  of  machine  design,  operating 
conditions  (response  to  excitation  changes  as  a  function  of  it’s  operating 
state  /  environment),  and  LAV’s  health 

Because  it  contains  a  lot  of  information  that  relates  to  various  excitation  sources, 
vibration  is  often  the  signal  of  choice  for  monitoring.  With  proper  acquisition, 
processing,  and  analysis,  you  can  relate  components  of  vibration  signals  to  the 
components  of  the  machine  of  interest. 
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Figure  11.15:  LAV  Health  Monitoring 


11.6.6.4  Signal  Source  Possibilities 

•  Mechanical  Systems  with  Rotation  and  Reciprocating  Components 

•  Engines 

•  Gearboxes 

•  Tires 

•  Brakes 

•  A/C,  Engine  Cooling 

•  Transmissions 

•  Motors  /  Generators 

•  Turbines 

•  Bearings 

•  Compressors 

•  Pumps 

•  Power 
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11.6.6.5  Vibration  Excitation  Sources 

Let’s  consider  some  vibration  sources  of  a  generic  operating  machine.  Some 
vibration  sources  are  due  to  machine  design:  slot  frequency  /  EM  related,  Gears, 
Coupling,  mechanical  resonance,  and  bearings  are  some  examples.  Other  sources 
result  from  potential  problems:  mechanical  looseness,  unbalance,  and  alignment. 
All  of  these  vibration  sources  combine  into  a  vibration  signal  that  can  be  measured 
[11- 


Mechanical 

looseness 


Bent  Shaft 
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Bears 


Blade  Pass/ 
Fluid  Related 
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EM  related 


Alignment 


Mechanical 
Resonances  Couplings 


Journal  (Fluid  Film) 
Bearings 

Rolling  Element 
Bearings 


Figure  11.16:  Gearbox  excitation  source 


11.6.6.6  Other  Possible  Signal  Sources 

There  are  a  number  of  other  available  signals  to  consider  when  building  a  machine 
condition  monitoring  system  for  LAV.  We’ve  already  mentioned  measurement  of 
static  vibration  signals,  other  common  possibilities  include  temperature,  pressure, 
flow,  and  level. 

•  Integrate  signals  &  functionality  “As  Needed” 

-  Temperature 

-  Pressure 
Flow 
Level 

-  Images  -  Light  or  Thermal! 
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11.6.6.7  The  Dynamics  of  Vibration 

There  are  several  approaches  to  measuring  vibration.  One  common  way  is  to 
measure  the  overall  vibration  level.  When  you  do  so,  you  combine  the  signal 
sources  together  into  a  single  aggregate  measurement.  As  a  simple  example,  one 
might  check  the  static  vibration  level  against  some  pre-defined  limit  to  determine  if 
manufacturer’s  specifications  are  exceeded  and  maintenance  is  required. 

Although  the  static  measurement  approach  is  appropriate  for  some  applications, 
others  require  the  more  robust  viewpoint  offered  by  dynamic  measurement.  Such  a 
measurement  allows  you  to  examine  a  signal  in  terms  of  the  components 
mentioned  above.  As  we’ll  see,  the  dynamic  vibration  signal  contains  frequency- 
domain  information  that  can  be  used  to  reduce  false  alarms,  assess  problem 
severity,  and  assist  with  diagnosis. 

•  Measurement  viewpoints 

-  Static 

•  Level 

•  Trending 

•  Alarming 

•  Dynamic 

-  FFT 

-  Octave  Analysis 

-  Order  Analysis 

-  Wavelet  Analysis 


11.6.6.8  LA V  Condition  Analysis 

Processing  for  machine  condition  monitoring  is  a  type  of  translation.  Processing 
transforms  the  raw  signal  viewpoint  from  your  transducer  into  a  viewpoint  that 
eases  analysis.  Analysis  for  MCM  often  boils  down  to  comparison:  current 
measurements  are  compared  to  or  assessed  in  terms  of  past  measurements. 

•  Acquire  and  now... 

o  Process  &  Analyze 

■=>  Assess  Machine  Condition 

<=>  Assist  with  Diagnosis 

•  For  Machine  Condition  Analysis 

^  Processing  =  Translation 
■=>  Analysis  =  Comparison 
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11.6.7  Signal  Analysis  for  Diagnostics 
11.6.7.1  Signal  Processing  =  Translation 

So,  what  exactly  do  we  mean  by  processing? 

To  answer  this  question,  let’s  continue  with  the  acceleration  signal  that  shows  the 
signal. 

This  Figure  11.17  shows  how  the  acceleration  amplitude  varies  as  a  function  of 
time.  Although  some  repeating  components  are  visible,  the  pattern  appears 
complex.  Such  complexity  is  typical  of  the  sound  or  vibration  that  you  might 
measure  from  any  operating  machine. 

To  tame  this  complexity,  you  might  apply  a  power  spectrum,  as  shown  here. 

By  depicting  signal  magnitude  as  a  function  of  frequency,  this  type  of  analysis  can 
often  better  distinguish  source-related  signal  components.  Periodic  signal 
components  appear  as  spikes  in  this  graph  [1], 


Figure  11.17:  Power  Spectrum  Overcomes  Time  Domain  Signal  Complexity 


11.6.7.2  Frequency  Analysis 

Fourier’s  theorem  states  that  any  waveform  in  the  time  domain  can  be  represented 
by  the  weighted  sum  of  sines  and  cosines.  The  same  waveform  can  then  be 
represented  in  the  frequency  domain  as  a  pair  of  amplitude  and  phase  values  at 
each  component  frequency. 

The  Fast  Fourier  Transform  (FFT)  transforms  digital  samples  from  the  time  domain 
into  the  frequency  domain.  Each  frequency  component  is  the  result  of  a  dot 
product  of  the  time  signal  with  the  complex  exponential  at  the  component 
frequency. 
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The  DC  component  is  the  dot  product  of  x(n)  with  [cos(0)-jsin(0)],  or  with  1 .0. 

The  first  “bin”,  or  frequency  component,  is  the  dot  product  of  x(n)  with  cos(2pn/N)- 
jsin(2pn/N).  Here,  cos(2pn/N)  is  a  single  cycle  of  the  cosine  wave,  and  sin(2pn/N) 
is  a  single  cycle  of  a  sine  wave. 

In  general,  the  real  part  of  FFT  bin  k,  Re[X(k)],  is  the  dot  product  of  x(n)  with  k 
cycles  of  the  cosine  wave,  and  the  imaginary  part  of  bin  k,  lm[X(k)],  is  the  dot 
product  of  x(n)  with  k  cycles  of  the  sine  wave. 
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Figure  11.18:  Based  on  the  Fast  Fourier  Transform  (FFT) 


Figure  11.19:  Dot  product  of  signal  with  cosines  &  sines 


11.6.7.3  Order  Analysis 

When  dealing  with  rotating  machinery,  you  can  often  hear  noise  and  feel  vibration 
created  by  the  parts,  such  as  bearings,  gears,  and  blades,  associated  with  the 
rotating  components.  Vibration  of  the  rotating  components  creates  noise  and 
vibration  signals.  The  machine  rotational  speed  is  the  source  of  these  signals,  and 
the  frequency-domain  representations  of  noise  and  vibration  behave  as  harmonics 
of  the  machine  rotational  speed.  In  many  industries,  the  harmonics  related  to  the 
rotational  speed  are  referred  to  as  orders,  and  the  corresponding  harmonics 
analysis  is  called  order  analysis. 
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Figure  1 1 .20:  Order  Spectrum  of  a  PC  Fan  with  Seven  Blades  and  Four  Coils 

Order  analysis  is  a  powerful  tool  for  engineers  and  scientists  to  better  understand 
the  condition  of  rotating  machinery.  Order  analysis  can  be  used  when  a  machine 
runs  at  a  constant  speed  or  when  the  rotational  speed  varies  [1], 
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Figure  1 1 .22:  Order  domain  Analysis  Fixed  Frequencies 


11.6.7.4  Fractional  Octave  Analysis 

To  get  a  feel  for  how  comparison  is  done  with  the  assistance  of  an  analysis  tool, 
consider  doing  the  job  with  fractional  octave  analysis.  Fractional  octave  analysis  is 
a  type  of  frequency-domain  analysis — it  examines  the  frequency  content  of  a 
signal.  It  does  so  by  dividing  the  spectrum  up  into  constant-bandwidth  octave 
bands,  which  are  commonly  presented  on  a  logarithmic  frequency  scale  as  a  bar 
graph. 


Examines  signals  in  the  frequency  domain 

Divides  frequency  domain  into  manageable  octave  bands 

Log  frequency  scale 
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Figure  11.23:  Factional  Octave  Analysis 

Fractional  octave  analysis  proves  useful  for  comparison  of  the  frequency  content  of 
a  signal  for  several  reasons: 

•  “Smart  Data  Reduction”  -  while  standard  FFT-based  power  spectrum  might 
return  256,  512,  etc,  measurements,  as  frequency  bins,  Octave  analysis 
typically  returns  20  or  so  measurements  as  octave  bands.  Fewer 
measurements  means  that  the  job  of  comparison  is  simplified  and  that  the 
data  logging  /  trending  portion  of  an  MCM  won’t  need  to  churn  through  as 
much  data. 

•  Based  on  IEC  /  ANSI  standards  -  Standards  have  defined  how  to  perform 
fractional  octave  analysis,  so  if  you  work  with  a  standards-compliant 
fractional  octave  tool  (such  as  what’s  included  with  the  Sound  &  Vibration 
Toolset  for  LabVIEW),  you  will  get  consistent  results  that  you  might 
compare  with  other  measurements  taken  under  the  auspices  of  the  same 
standard  [1], 


11.6.7.5  Wavelet  Analysis 

Wavelets  offer  a  much  better  signal  representation  leading  to  a  good  spatio- 
temporal  decomposition.  We  will  discuss  Wavelet  analysis  in  a  later  section. 


11.6.8  Conclusion  What  we’ve  demonstrated  thus  far  involved  acquisition,  signal 
processing,  and  analysis  that  you  can  apply  to  LAV  condition  monitoring.  These 
elements  might  serve  as  a  portion  of  a  front-end  for  a  comprehensive  LAV 
condition  monitoring  system.  By  sharing  data  over  a  LAN,  the  Internet,  or  even 
wireless,  you  could,  for  instance,  monitor  multiple  machines,  generate  HTML 
status  reports,  and  remotely  check  in  on  plant  status  from  a  home  PC. 

•  After  Acquisition,  Signal  Processing,  and  Analysis,  the  tasks  are: 
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-  Report  Generation  (HTML) 

-  Data  Sharing  (between  programs,  across  the  network  or  Wireless) 

-  Remote  Monitoring  (Across  Inter-,  Intra-net,  Wireless) 

In  the  next  report,  we  will  detail  them  with  specific  reference  to  LAV  CBM. 
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11.7.1  Condition  Based  Maintenance  [1],  [2] 


1 1. 7. 1. 1  Definition 

CBM  is  initiated  by  sensing  equipment  condition.  CBM  is  defined  as  a  set  of 
actions  taken  as  a  consequence  of  knowing  the  current  operating  status  of  the 
equipment.  Determining  current  equipment  operating  status  is  accomplished  in 
three  basic  ways: 

□  By  using  sensors  and  computers  that  are  embedded  into  the  operating 
equipment  and  monitored  on-the-fly, 

□  By  applying  portable  sensing  equipment  that  marries  up  to  an  interface  or 
wiring  harness  to  “read”  embedded  sensors,  or  to  apply  the  sensor  itself, 
such  as  a  stand-alone  wear  measurement, 

□  By  using  manual  gauges  or  instruments,  such  as  a  tire-wear  gauge 

We  should  be  clear  as  to  the  intent  of  CBM,  as  well  as  its  capability.  The  intent  of 
CBM  is  to  perform  maintenance  only  when  there  is  objective  evidence  of  need. 
The  technical  capability  of  CBM  is  to  identify  current  equipment  conditions.  What 
we  do  with  these  condition  indicators  is  more  than  a  matter  of  being  able  to 
schedule  maintenance  or  forecast  failure.  Done  right,  with  objective  evidence  of 
need  in  hand,  we  forecast  or  schedule  maintenance  tasks.  However,  steps  must 
be  taken  beforehand — before  CBM  is  applied  to  a  given  task — to  ensure  it  is  a 
cost-effective  task  in  the  first  place. 


11.7.1.2  Major  CBM  Programs  in  the  Services 

We  can  consider  the  following  four  programs,  based  on  their  size  and  scope: 

□  Joint  Strike  Fighter  Prognostic  Health  Management  (JSF-PHM) 

□  Navy  Integrated  Condition  Assessment  System  (ICAS) 

□  Army  Diagnostic  Improvement  Program  (ADIP) 

□  Integrated  Mechanical  Diagnostics,  Health  Usage  &  Monitoring  System 
(IMD-HUMS),  a  helicopter  CBM  program 

The  JSF  is  a  new  design  weapon  system,  just  completing  concept  development. 
JSF  PHM  represents  what  can  be  done  with  current  technology  when  weapon 
system  design  and  CBM  design  go  hand-in-hand.  The  other  programs  address 
improved  CBM  capabilities  for  legacy  weapon  system  fleets. 

This  report  will  examine  the  three  programs,  ADIP  and  IMD-HUMS  by  describing 
the  concept  and  block-diagram.  In  other  words,  this  report  describes  the 
operational  concept  in  simplified  terms  to  facilitate  comparison  of  basic  program 
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concepts,  and  we  also  show  a  similar  block  diagram  for  each  program  which 
identifies  the  major  components  and  how  the  programs  differ  at  this  level. 

11.7.1.3  CBM  System  Block  Diagram 


CBM  System  Block  Diagram 


(On  System) 


(At  System) 


Weapon  System 


O-Level 
Maintenance 


(Off  System) 


Intermediate  /  Depot 
Level  Maintenance 


Embedded 

Sensors, 


Figure  11.24:  CBM  System  Block  Diagram 


Overview 

For  the  CBM  system  block  diagram,  we  can  introduce  the  terms  of  on-system,  at- 
system  and  off-system  (system  in  this  latter  instance  referring  to  weapon  system), 
instead  of  using  the  on-board/off-board  terms.  This  stems  from  the  need  to 
introduce  the  use  of  portable  equipment  that  performs  condition  monitoring  and 
runs  the  IETM. 

□  On-system  -  the  embedded  (on-board)  sensors  and  computers  from  which 
condition-monitoring  data  is  collected.  This  also  includes  the  data  bus  or 
wiring  harness  and  connectors  that  carry  the  signals  from  the  sensors. 

□  At-system  -  the  portable  maintenance  aid  and/or  portable  sensoring 
equipment  used  periodically  to  check  equipment  health. 

□  Off-system  -  this  is  synonymous  with  off-board,  except  concerning  Navy 
ships.  Navy  ships  keep  the  workstations  on-ship;  so;  from  a  NAVSEA 
perspective,  everything  is  on-board.  We  will  call  this  shipboard  when 
discussing  Navy  surface  ship  CBM. 
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Open  Systems  Architecture 

A  block  diagram  can  help  visualize  the  key  interfaces  and  standards  that  are 
fundamental  to  open  systems  architecture  design.  The  standards  committees  of 
the  Institute  of  Electronic  and  Electrical  Engineers  (IEEE)  and  the  Society  of  Auto¬ 
motive  Engineers  (SAE)  play  key  roles  for  defining  interface  and  component 
standards  (as  do  others).  We  highlight  key  areas  where  these  standards  underpin 
an  open  architecture  design. 

Data  Bus 

The  data  bus  specification  is  a  key  design  element  to  achieving  open  systems 
architecture. 

□  Physically,  a  data  bus  replaces  part  of  a  weapon  system  wiring  harness  and 
significantly  reduces  harness  wiring.  It  may  be  fiber-optic  or  wire. 

□  Functionally,  the  data  bus  is  a  local  area  network  (LAN)  for  the  vehicle  and 
can  have  redundant  capability  for  fault-recovery  purposes,  as  it  does  in 
most  modern  fighter  aircraft  and  ground  fighting  vehicles. 

□  From  an  interface  standpoint,  a  data  bus  is  an  interface  portal  providing 
access  from  external  devices  to  embedded  sensors  and  computers. 

There  are  only  a  handful  of  data  bus  definitions.  If  the  weapon  system  employs  an 
industry  standard  data  bus,  such  as  the  J1708  or  J1939  data  buses  specified  by 
SAE,  or  the  Mil-Std-1 553  data  bus,  then  the  hardware  interface  to  the  embedded 
computer  is  a  well-described  entity  which  facilitates  third-party  commercial  off-the- 
shelf  (COTS)  component  suppliers.  The  data  bus  does  not  have  to  comply  with  an 
industry  standard  to  enable  open  systems,  as  long  as  the  definition  of  signals  is 
openly  available,  such  as  the  NAVSEA  Integrated  Carrier  Advanced  Net-work 
(ICAN)  program,  which  is  now  specified  for  a  fiber-optic  backbone  in  the  new 
generation  of  aircraft  carriers. 

Messages  on  the  Bus 

Open  Architecture  design  facilitates  by  specifying  the  message  traffic  on  the  data 
bus  in  some  standard  fashion.  SAE  has  learned  from  the  earlier  Mil-Std-1 553  data 
bus  experience  in  this  regard.  SAE  has  defined  companion  message  proto-cols  for 
the  hardware  bus.  Mil-Std-1 553  does  not  do  this,  which  forces  a  retrofit  systems 
integrator  or  CBM  developer  to  learn  the  message  protocol  for  every  sub-system, 
each  of  which  typically  differs  significantly  from  the  other. 

Embedded  Sensors 

Fundamental  to  all  CBM  systems  is  a  suite  of  embedded  sensors  of  various  types. 
The  more  sophisticated  the  system,  the  more  diverse  the  sensor  technologies  and 
the  greater  the  density  of  sensors  employed.  The  IEEE  now  specifies  a  sensor 
object  model  that  defines  sensor  features.  The  SAE  does  this  also.  Older  weapon 
systems  accessed  sensors  directly  via  a  wiring  harness  routed  to  a  common 
connector;  newer  systems  use  a  data  bus.  Some  ground  systems  in  the  Army  have 
both,  which  may  complicate  access  to  data.  Some  older  aviation  systems  are  also 
only  partially  integrated,  again  limiting  data  access. 
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Embedded  Computers 

All  new  weapon  systems  employ  on-board  computers,  in  many  cases,  in 
conjunction  with  data  acquisition  channels  and  data  storage  capacity.  Embedded 
computer  design  generally  follows  industry  standards,  depending  on  the  form 
factor,  processing  power,  storage  requirements,  and  interface  needs  of  the  system. 
An  open  system  architecture  design  will  specify  a  particular  computer  architecture 
and  also  provide  input/output  (I/O)  expansion  capability  using  a  known  interface 
standard. 

Portable  Maintenance  Aid  (PMA) 

The  PMA  may  or  may  not  be  part  of  the  CBM  data-monitoring  and  data-collection 
effort.  In  more  sophisticated  CBM  systems,  the  PMA  runs  an  IETM  that  uses  the 
PMA  to  connect  to  the  embedded  data  bus  and  extract  sensor  information  to  aid 
the  troubleshooting  process.  The  PMA  links  to  the  off-board  (or  analytic)  part  of  the 
CBM  system  to  download  troubleshooting  and/or  “health  check”  information  to  the 
database  and  trend  analysis  system. 

The  computer  architecture  of  the  PMA  is  most  often  based  on  a  popular  portable 
PC  architecture,  such  as  Intel  or  Apple,  and,  more  recently,  the  Palm  handheld 
devices.  This  practice  significantly  lowers  acquisition  costs,  though  it  places  a 
burden  on  the  systems  integrator  to  address  “ruggedization”  features. 

Off-board  Computerized  Maintenance  Management  Systems  (CMMS) 

The  off-board  part  of  the  CBM  system  is  typically  a  networked  workstation 
environment  using  the  Ethernet  (IEEE  802.1)  standard.  One  computer  generally 
acts  as  the  interface  to  the  embedded/PMA  components,  while  the  database 
resides  on  another  computer  somewhere  on  the  network  and  operates  in  a  shared 
environment. 

On  the  industrial  side  of  CBM  and  CMMS,  suppliers  typically  address  these 
standards  in  their  product  offerings. 

Turn-key  CMMS  Solutions 

The  commercial  CBM  industry  provides  a  range  of  system  solutions,  from 
individual  software  packages  to  complete  turnkey  systems.  The  Navy’s  ICAS 
system  is  an  example  of  a  CBM  system  that  started  as  a  turnkey  package  of 
sensors  and  an  off-board  CMMS  system  and  gradually  added  capabilities  from  a 
base  plat-form. 

Database 

The  database  is  a  key  area  for  open  standards;  it  is  typically  addressed  when  se¬ 
lecting  the  supplier  of  the  database  management  system.  The  rise  of  Internet  func¬ 
tionality  and  web-enabled  commerce  supply  chains  is  creating  a  new  generation  of 
database  concepts  that  may  soon  replace  the  traditional  database  suppliers. 
These  are  all  based  on  open  Internet  standards,  and  will  create  a  new  dimension 
for  C4I  systems  architecture. 
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1 1. 7. 1.4  Commercial  CBM  infrastructure 

A  CBM  infrastructure  has  been  built  over  time  in  the  commercial  sector  that  helps 
guide  its  effective  employment  and  promotes  sharing  of  information  across 
industries.  This  infrastructure  represents  a  set  of  resources  for  military  programs  to 
build  upon  in  their  own  CBM  programs. 

Being  able  to  capitalize  on  the  richness  of  the  commercial  CBM  sector 
infrastructure  is  one  of  the  principal  reasons  to  design  weapon  system  and 
associated  CBM  programs  on  an  open  architecture  basis. 

The  commercial  machinery  sector  has  an  open-systems  forum  comprised  of  a 
consortium  of  companies  that  use  or  supply  CBM  technology — Machinery 
Information  Management  Open  Systems  Alliance  (MIMOSA).  MIMOSA  is 
comprised  of  over  50  companies  that  participate  in  an  open-exchange  of  ideas  and 
practices.  Substantial  benefits  are  available  to  the  Services  and  their  suppliers  by 
joining  MIMOSA.  This  could  promote  a  beneficial  exchange  among  all  parties, 
ensuring  that  MIMOSA  open  standards  reflect  Service  requirements  for  CBM  and 
other  predictive  maintenance  applications.  For  example,  it  was  noted  at  a  recent 
CBM  symposium  that  requirements  for  exchanging  shipboard  maintenance  in¬ 
formation  could  be  included  in  MIMOSA’S  open  conventions  and  protocols. 

A  number  of  universities  sponsor  centers  focused  on  reliability,  machinery 
diagnostics  or  CBM.  Generally,  these  centers  are  integral  to  the  universities’ 
engineering  departments. 

In  the  commercial  sector,  there  are  professional  societies  that  focus  on  condition¬ 
monitoring  and  professional  journals  and  periodicals  dedicated  to  examining 
technology,  applications  and  economic  considerations  in  CBM  and  other 
maintenance  concepts.  A  wide  range  of  articles  provides  relevant  information 
pertaining  to  CBM  technology  and  business  case  discussions. 


11.7.2  CBM  in  Army  [1],  [2] 

1 1. 7.2. 1  Concept 

ADIP  is  aimed  at  improving  the  diagnostics  and  prognostics  of  all  Army  weapon 
systems  and  equipment  by  the  application  of  common  technologies  across  multiple 
systems.  ADIP  addresses  all  Army  commodities  and  systems.  In  fact,  it  ad-dresses 
more  types  of  equipment  than  any  other  Service  program  and  is  the  broadest  in 
scope  of  DoD’s  legacy  equipment  maintenance  improvement  pro-grams. 

ADIP  has  three  time-phased  “thrusts”  grouped  according  to  the  time  frame 
required  for  implementation.  The  Program  Manager  for  Test,  Measurement,  and 
Diagnostic  Equipment  (PM-TMDE)  oversees  the  program  through  a  series  of 
integrated  product  teams  whose  membership  is  drawn  from  equipment  program 
manager  (PM)  offices  and  Army  staff  agencies.  The  three  thrusts  are: 
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Short-term  -  immediate  technology  insertion  programs  to  improve  diagnostics 

Mid-term  -  to  develop  anticipatory  maintenance  capability  in  ground  vehicles  and 
helicopters 

Long-term  -  is  to  develop  an  embedded  diagnostics  proof-of-concept  for  a 
common  architecture  and  approach  (similiar  to  the  JSF  PHM  embedded 
architecture  design  goals). 


ADIP  Concept  Today 


Data  Collected  On  or  At  System  /  Prediction  Generated  Off-Board 


Portable 

Maintenance 

Aid 


GCSS-Army 


•  Vehicle  may  not  have  data  bus 

•  Portable  Maintenance  Aid  -  centric. 

—  Collects  sensor  health'  data 

-  Fau/t  isolation  accomplished  by  maintains 
using  sensor -coupled  IETM 

-  Data  automatically  caplured  and  stored  at 
GCSS-Army  through  a  standard  data 
exchange  protocols 


ANTICIPATORY  LOGISTICS 


Figure  11.25:  ADIP  Concept  Today 


The  ADIP  CBM  concept  today  is  to  access  on-board  data  using  the  PMA  as  the 
primary  data  collection  and  communication  tool.  The  PMA  runs  sensor  health 
checks,  and  the  sensor-coupled  IETM  automatically  collects  the  data  and  transmits 
it  to  GCSS-Army. 


PM-TMDE  and  PM-GCSS-Army  have  jointly  developed  software  interfaces  to 
GCSS-Army  that  apply  to  IETM  data  capture  and  to  vehicle  health  data. 
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ADIP  Concept  with  TACOM  Telemaintenance 
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Telemaintenance  augments  PMA  by 
near  real-time  vehicle  health 
monitoring  via  satellite. 


TELELOGISTICS 


Figure  11.26:  TACOM  Tele-maintenance 


Tele-maintenance,  which  means  collecting  of  on-board  vehicle  health  data  and 
transmitting  it  via  long-range  communication  media  to  a  maintenance  support 
center  for  analysis,  is  under  development  by  the  Tank-Automotive  and  Armaments 
Command  (TACOM)  in  Detroit.  LIA  is  funding  and  supporting  TACOM  in  this  effort. 
Like  JSF’s  autonomic  logistics,  Tele-maintenance  supports  Tele-logistics  by  linking 
the  maintenance  center  and/or  the  individual  vehicle  to  the  logistics  system 
through  the  maintenance  center.  At  TACOM,  the  Electronic  Maintenance  System 
(EMS)  handles  the  sensor-coupled  IETM  and  the  PMA  collection  of  vehicle  sensor 
health  data.  EMS  integrates  the  resulting  information  into  the  logistics  system  and 
enables  real-time  tracking  of  vehicles  and  weapon  systems  and  their  maintenance 
status. 
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11.7.2.2  Block  Diagram 


ADIP  Block  Diagram 
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Figure  11.27:  ADIP  Block  Diagram 


The  on-board  hardware  components  of  ADIP  are  COTS,  delivered  as  a  package 
by  the  engine,  transmission  and  other  vehicle  subsystem  OEMs,  and  integrated 
into  the  vehicle  by  the  vehicle  OEM. 


Embedded  Sensors 

Sensors  in  Army  vehicles  come  in  two  distinct  forms,  those  on  mechanically  con¬ 
trolled  engines  and  those  on  electronically  controlled  engines.  The  older 
mechanical  engines  are  being  phased  out  of  Army  and  U.S.  Marine  Corps  (USMC) 
inventory  as  part  of  vehicle  remanufacturing  programs,  such  as  the  USMC  Medium 
Tactical  Vehicle  Replacement  program,  or  new  vehicle  development,  such  as  the 
Army  Family  of  Medium  Tactical  Vehicle  program.  Vibration  sensors  are  not 
presently  in  the  Army  suite  of  sensors  used  for  CBM  purposes  as  commercial 
diesel  engine  OEMs  have  not  provided  them. 

PMA  Functionality  for  CBM 

The  PMA  reads  the  vehicle  sensors  either  directly  via  a  common  multiple-pin 
connector,  or  by  connecting  to  the  data  bus  and  capturing  the  data  from  sensors 
that  have  been  processed  by  the  on-board  engine  control  unit.  The  PMA  collects 
the  sensor  data  through  a  stand-alone  process  known  as  a  health  check,  or  it 
selectively  interrogates  only  those  sensors  appropriate  to  a  troubleshooting 
session  for  a  known  symptom,  using  the  sensor-coupled  IETM. 

GCSS-Armv  Interface  and  Interaction 

One  of  PM-TMDE’s  major  CBM  initiatives  has  been  the  development  of  the 
Predictive  Maintenance  Module  (PMM),  previously  known  as  the  Failure  Analysis 
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and  Maintenance  Planning  System  (FAMPS).  This  is  essentially  a  database 
capability  for  collecting,  storing,  analyzing  and  acting  on  equipment  condition 
trends  identified  in  the  data.  There  is  a  high  degree  of  collaboration  with  PM- 
GCSS-Army  and  its  Army  Combined  Arms  Support  Command  (CASCOM)  parent. 
This  sets  the  ADIP  program  apart  from  other  CBM  system  developments,  given  the 
extent  and  nature  of  the  interfaces  developed  and  the  modifications  made  to  the 
GCSS-Army  information  system  to  support  predictive  maintenance  functionality. 

Database 

The  Army  databases  that  stores  and  analyzes  vehicle  health  data  contains  many 
separate  compartments  of  vehicle  health  information.  As  a  result,  the  database  is 
structured  to  facilitate  individual  weapon  system  capabilities  in  health  data 
collection.  For  example,  separate  data  definitions  are  provided  for  TED  (Turbine 
Engine  Diagnostics),  a  program  apart  from  ADIP,  but  for  which  ADIP  makes 
provisions  for  incorporation  into  the  GCSS-Army  PMM. 

The  power  of  the  predictive  nature  of  the  system  is  extended  by  correlation  with 
geographic  and  weather  data,  which  is  collected  from  NOAA,  the  National  Oceanic 
and  Atmospheric  Agency,  and  stored  in  the  GCSS-Army  data  base.  This  data  can 
then  be  used  to  determine,  for  example,  environmental  impacts  on  equipment 
degradation  and  maintenance  requirements. 


1 1.7. 2.3  Case  Study:  Ml  Abrams  main  battle  tank  (MBT)  [3] 

The  U.S.  Army’s  current  maintenance  practices  for  the  Ml  Abrams  main  battle 
tank  (MBT)  mainly  employ  manual  diagnostic  procedures.  Efforts  are  continually 
underway  to  make  improvements  in  materials,  electronics/control  systems,  and 
automated  processes  to  increase  the  reliability  and  performance  of  the  equipment. 
Nevertheless,  current  manual  processes  as  well  as  automated  enhancements  still 
generally  verify  only  whether  the  operational  states  are  within  or  out  of  tolerance. 
For  this  system,  and  more  particularly  for  future  high-value/high  cost  vehicles  and 
platforms,  there  is  a  need  to  achieve  real-time  engine  condition  monitoring  and 
prediction  of  near-term  vehicle  health  and  readiness.  This  enhanced  technology 
promises  to  improve  logistics  and  maintenance  processes  by  enabling  reductions 
in  maintenance  staff  hours,  improvements  in  diagnostic  performance,  increasing 
readiness,  and  providing  the  information  required  to  optimize  maintenance 
scheduling  based  on  need.  This  paper  describes  a  current  research  and 
development  project  aimed  at  fielding  a  proof-of-concept  operational  prototype 
engine  health  monitoring  and  prognostic  system. 
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Figure  11.28:  Ml  Abrams  MBT 


Under  an  Interagency  Agreement  with  the  U.S.  Army  Logistics  Integration  Agency, 
Pacific  Northwest  National  Laboratory  (PNNL)  is  developing  a  prototype 
diagnostic/prognostic  system  for  the  MBT’s  AGT1500  turbine  engine  that  uses 
artificial  neural  networks  to  diagnose  and  predict  faults.  The  operational  prototype 
system  is  called  TEDANN,  for  Turbine  Engine  Diagnostics  using  Artificial  Neural 
Networks  (Greitzer  et  al.  1997;  llli  et  al.  1994;  Kangas  et  al.1994).  The  main  tasks 
of  the  TEDANN  project  are  to  develop  prototype  data  acquisition  hardware,  to 
design  and  implement  health  monitoring  software,  and  demonstrate  the  proof-of 
concept  system. 

TEDANN  receives  input  from  48  sensors  mounted  on  the  AGT1500  engine.  Of 
these  sensors,  32  are  factory  installed  for  engine  control  and  basic  diagnostics 
performed  by  the  engine  control  unit.  The  other  sixteen  sensors — retrofitted  to  the 
engine  using  a  wiring  harness — include  seven  pressure  sensors,  six  temperature 
sensors,  two  chip  detectors,  a  vibration  sensor  and  an  inclinometer.  Advanced 
microsensor  technology  has  been  exploited  in  this  and  related  projects  (Wilson  et 
al.  1999).  The  thermodynamic  (temperature,  pressure,  RPM,  etc.)  sensors  are 
located  at  strategic  points  along  the  gas  flow  in  the  engine  to  provide  more  detailed 
thermodynamic  picture  of  the  engine’s  state.  The  TEDANN  prototype  is  contained 
in  an  enclosure  about  one  foot  square  and  3  inches  high.  The  sensor  signals  are 
conditioned  using  two  printed  circuit  boards,  multiplexed  to  a  data  acquisition  card, 
and  then  analyzed  by  a  Pentium  microprocessor. 

If  fully  deployed  in  the  field,  the  TEDANN  system  would  be  integrated  with  other 
electronic  systems  onboard  the  tank. 

TEDANN  is  being  developed  using  model-based  diagnostics  and  artificial  neural 
networks.  This  technology  allows  the  diagnostic/prognostic  system  to  model 
normal  engine  performance,  learn  to  recognize  deviations  from  normal  behavior, 
and  classify  these  deviations  as  conditions  requiring  maintenance  attention. 
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Sensor  Input  Stream 


Data 

Figure  11.29  Diagnosis  and  Prognosis  on  TEDANN 

The  sensor  values  are  first  analyzed  to  determine  if  they  are  valid,  i.e.,  within 
expected  operating  ranges.  If  any  sensor  is  determined  to  be  faulty,  a  modeled 
value  is  substituted  for  the  observed  value.  Artificial  neural  networks  and  a  set  of 
rules  are  used  to  model  the  sensor  values  and  support  sensor  validation.  Following 
the  sensor  validation,  the  sensor  data  are  processed  by  diagnostic  modules. 
Diagnostic  processing  includes  rule-based  and  ANN-based  analyses.  Rule-based 
analyses  check  to  see  if  one  or  a  few  sensor  values  exceed  thresholds  or  fail  to 
follow  thermodynamic  relationships.  ANN-based  analyses  provide  diagnoses  of 
complex  faults  requiring  parallel  analysis  of  a  large  number  of  sensors.  An 
unsupervised,  self-organizing  ANN  classifies  engine  operations  into  states,  such 
as  low-idle,  tactical  idle,  full  power,  etc.  Other  supervised,  feed-forward  ANNs 
perform  engine  modeling  and  pattern  recognition  to  diagnose  specific  faults  and 
conditions.  Such  model-based  diagnoses  are  output  as  parameters  that  are 
analyzed  in  TEDANN’s  prognostic  module. 
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11.7.3  CBM  in  Army  Helicopter  equipments  [1],  [2] 


11.7.3.1  Concept 

The  IMD-HUMS  is  a  Commercial  Operations  and  Support  Savings  Initiative 
(COSSI)  program.  This  is  an  Office  of  the  Secretary  of  Defense  (OSD)-sponsored 
program  to  accelerate  fielding  of  dual-use  technologies  (i.e.,  commercial)  that 
satisfy  military  needs  and  have  high  potential  to  reduce  operations  and  support 
costs.  IMD-HUMS  stemmed  from  helicopter  safety  problems  in  the  Presidential 
helicopter  fleet;  a  1993  White  House  requirement  memo  initiated  the  program. 

The  IMD-HUMS  program  integrates  and  tests  a  commercial/military  “dual  use” 
mechanical  diagnostic  system  from  BFGoodrich  on  the  H-53  and  H-60  Sikorsky 
helicopters.  This  program  is  coordinating  with  the  Joint  Advanced  Health  Usage  & 
Monitoring  System  (JAHUMS),  a  separate  CBM  technology  development  project, 
in  order  to  use  the  JAHUMS  project  for  risk  reduction  in  testing  key  technologies. 

There  are  a  number  of  other  HUMS  programs,  domestic  and  international,  that 
represent  a  source  of  lessons  learned  and  potential  collaboration.  Internationally, 
both  the  United  Kingdom  Ministry  of  Defence  and  the  Canadian  Defence  Forces 
have  developed  and  fielded  HUMS  for  helicopters.  The  U.S.  Army  PM-TIVIDE  is 
sponsoring  a  HUMS  program  for  the  Army  independent  of  both  IMD-HUMS  and 
JAHUMS,  working  with  the  South  Carolina  National  Guard.  These  various  efforts 
appear  to  be  legitimate  sources  for  effective  collaboration. 


IMD-HUMS  Concept 
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Figure  11.31:  IMD-HUMS  Concept 


130 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  1 


IMD-HUMS  provide  for  full-time  in-flight  monitoring  and  collection  of  engine  and 
mechanical  drive  systems  health  information.  This  monitoring  process  includes 
flight  regime  information  necessary  to  make  prognostic  forecasts  of  remaining 
equipment  life,  and  structural  and  operational  usage. 

When  the  helicopter  is  on  the  ground,  the  data  transfer  cartridge  containing  in-flight 
condition  data  is  retrieved  and  sent  to  the  Naval  Aviation  Logistics  Command 
Management  Information  System  (NALCOMIS)  Optimized  Organizational 
Maintenance  Activity  (OMA),  where  it  is  analyzed  for  early  identification  and 
correction  of  degraded  components  in  the  engine,  drive  train,  and  rotor  systems  of 
the  helicopter. 

IIVID-HUMS  provides  for  cockpit  display,  alerting  aircrew  of  aircraft  health  data 
considered  to  have  an  impact  on  immediate  flight  safety.  A  portable  computer 
functions  as  a  portable  maintenance  aid  running  a  traditional  Class  3-4  IETM  (i.e., 
not  sensor-linked). 


1 1. 7.3.2  Block  Diagram 
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Figure  11.32:  IMD-HUMS  Block  Diagram 


Major  on-board  hardware  components  include:  (1)  the  main  processor  unit  (MPU), 
whose  principal  functions  are  shown  in  the  chart,  (2)  an  optical  tracker  unit,  used 
for  rotor  track  and  balance  evaluation,  (3)  data  concentrators,  and  (4)  an  array  of 
various  sensors.  Vibration  and  temperature  sensor  data  are  collected  to  aid  flight 
regime  analysis. 
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An  IETM  resides  on  a  portable  maintenance  aid  that  reads  a  PCMCIA  card  loaded 
with  selected  in-flight  condition  data  used  to  assist  troubleshooting  and  repair. 


11.7.4  Summary 

JSF  PHM  is  the  most  comprehensive  technology  development  program  reviewed 
for  this  report.  It  is  the  DoD  leader  in  technical  capability  and  in  the  articulation  of 
program  goals  measured  by  appropriate  metrics.  And  it  has  the  longest  time 
horizon  (>40  years).  Additionally,  JSF  PHM  is  built  upon  an  open-systems 
architecture  with  the  integration  of  COTS  technology  where  feasible.  It  has 
pioneered  the  concept  of  autonomic  logistics. 

ADIP  addresses  the  most  diverse  fleets  of  weapon  systems  and  the  greatest 
numbers  and  kinds  of  equipment.  ADIP  has  pioneered  the  technology-enhanced, 
sensor-coupled  IETM.  It  has  a  vision  of  achieving  embedded  PHM  capability 
similar  to  the  JSF  program,  but  present  capability  uses  a  PMA-centric  approach  to 
capture  and  transmit  equipment  health  data  to  a  processing  center  that  can  mine 
the  data  for  predictive  information.  ADIP  has  worked  extensively  with  GCSS-Army 
to  develop  and  augment  GCSS-Army  with  a  predictive  maintenance  module 
capacity  and  has  specified  the  software  interfaces  and  data  elements  needed  to 
accomplish  this.  The  goals  of  ADIP  are  the  most  specific  shown,  but  still  to  be 
developed  are  program  metrics  to  monitor  progress  in  attaining  those  goals. 

ICAS  addresses  the  most  substantial  technical  challenges  reviewed  in  this  report 
as  measured  by  the  range  and  kinds  of  older  non-digital  ship  propulsion  and 
HM&E  systems  it  attempts  to  address.  It  limits  CBM  goals  to  cost  reduction  in  the 
form  of  reducing  man-hours  spent  recording  data  in  the  ship  logbook,  and  does  not 
address  logistics  support  linkage  or  integration.  Technically,  ICAS  is  an  adaptation 
of  the  trademarked  COTS  CBM  system  from  IDAX,  Incorporated,  and  is  self- 
contained  on  each  ship  that  implements  ICAS. 

IMD-HUMS  is  more  a  platform-specific  project  than  a  Service  CBM  program,  but  it 
does  address  multiple  helicopter  fleets.  It  has  designed  a  sophisticated 
methodology  for  in-flight  condition-monitoring  that  approaches  prognostic  capability. 
It  does  not  attempt  real-time  condition-reporting  or  downlinking  data  while  in-flight, 
but  it  does  provide  significant  capability  for  early  detection  of  impending  problems 
in  many  complex  mechanical  systems  associated  with  the  helicopter  drive  train. 
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11.8  Appendix:  6  -  Commercial  Practices  of  Maintenance  in 
Aviation 

11.8.1  Introduction 

1 1 .8.2  Airbus  Vs.  Boeing:  Modern  Aircraft  Maintenance 

11.8.3  MSG-3  (Maintenance  Steering  Group,  3rd  edition) 

1 1 .8.3.1  -  Development  of  Scheduled  Maintenance 

1 1 .8.3.2  -  Divisions  of  MSG-3  Document 

1 1 .8.3.3  -  Logic  Diagram 

1 1 .8.3.4  -  Task  Interval  Determinations 

1 1 .8.4  Monitoring  the  health  of  the  airplane  engine 
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11.8.1  Introduction 

Aviation  maintenance  technology  focuses  on  aircraft  airframe  and  power-plant 
maintenance.  This  section  focuses  on  three  aspects:  (1)  Comparing  the  aviation 
operation,  maintenance  environment  and  management  between  Boeing  and 
Airbus.  (2)  Understanding  the  MSG-3,  which  is  the  latest  maintenance  program  in 
Boeing  fleet.  (3)  Defining  requirements  for  monitoring  the  health  of  the  airplane 
engine.  The  material  is  extracted  from  some  of  the  references  cited. 


11.8.2  Airbus  Vs.  Boeing:  Modern  Aircraft  Maintenance 

In  the  Airbus  designing  process,  maintainability  is  already  under  consideration.  By 
applying  Fly-by-wire  technology  on  the  A330/A340  family,  and  a  long-time  Airbus 
design  feature,  has  contributed  to  make  maintenance  simpler.  Here  are  some 
illustrations  of  Airbus  maintenance  features: 

(1 )  One  aspect  of  maintenance  that  is  improving  is  engine  monitoring.  The  high 
cost  of  engine  removals  has  sparked  a  trend  toward  longer  time  on  wing. 
On  the  A340,  for  example,  parameters  are  easier  to  analyze,  and  this 
makes  it  easier  to  determine  the  right  time  to  remove  the  engine,  avoiding 
unnecessary  early  removals. 

(2)  A  significant  step  forward  for  Airbus  maintenance  is  the  centralized 
maintenance  computer.  Formerly,  built-in  test  equipment  was  scattered  and 
you  had  to  work  with  several  computers.  Aircraft  CMC  (central  maintenance 
computer)  gives  comprehensive  information  (including  history  of 
parameters)  in  plain  English. 

(3)  Datalink,  a  technology  that  provides  digital  information  flow  between  ground 
services  and  flight  decks,  via  the  satellite-based  ACARS  (Aircraft 
Communication  &  Address  Reporting  System)  allows  real-time  monitoring  of 
in-flight  aircraft.  Data  is  received  in  airport  and  forwarded  to  other  bases  if 
necessary.  Airbus  can  anticipate  what  kind  of  maintenance  equipment  and 
spare  parts  are  needed  at  the  next  stopover.  Experts  can  find  a  solution  that 
can  be  performed  during  flight. 

(4)  For  future  demand,  an  ever-more  integrated  avionics  suite  will  avoid  the 
coexistence  of  conflicting  software. 

Besides  Airbus,  Boeing  also  has  some  unique  components  and  features  in  its 
maintenance  system: 

(1)  MyBoeingFleet.com  is  a  website  that  customers  can  access  as  a  single 
point  of  contact  for  obtaining  virtually  all  the  information  they  need  to 
maintain  and  operate  their  Boeing  fleets.  Whether  ordering  spare  parts, 
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retrieving  technical  drawings  and  service  bulletins,  collaborating  with  other 
carriers  on  technical  issues,  sharing  fleet  data  or  even  filing  warranty  claims. 

(2)  To  further  improve  logistics  support,  Boeing's  innovative  GAIN  (Global 
Airline  Inventory  Network)  program  manages  the  supply  chain  for 
expendable  airframe  parts  and  saves  airlines  inventory-holding  costs. 

(3)  Airplane  Health  Management,  for  example,  is  an  integrated  family  of 
information  products  and  services  that  will  collect  monitor  and  analyze 
airplane  data  on  in-service  airplanes,  allowing  for  faster  repairs  and,  in 
many  cases,  the  ability  to  predict  faults  and  prevent  equipment  failures 
before  they  occur. 

(4)  Alteon  provides  comprehensive  learning  programs  for  maintenance 
technicians,  supported  by  computer-based  training  aids,  simulators,  and  on¬ 
site  sessions  at  customer  locations. 

(5)  Boeing  designs  ground  support  equipment,  apply  human-factors  research  to 
reduce  maintenance  errors,  conduct  a  variety  of  maintenance-related 
consulting  services  and  studies,  and  offer  periodic  maintenance  seminars  to 
help  airlines  improve  proficiency. 

(6)  Boeing  has  two  subsidiaries.  Continental  DataGraphics  provides 
customized  documentation  to  airlines,  including  parts  catalogs  and  digitized 
information.  Aerolnfo  Systems  develops  advanced  software  to  manage 
maintenance  activities. 

(7)  MSG-3  standard  (Maintenance  Steering  Group,  3rd  edition)  has  been 
successively  developed  by  the  industry  to  create  more  efficient  maintenance 
programs,  by  analyzing  failure  modes  and  their  level  of  criticality. 


11.8.3  MSG-3  (Maintenance  Steering  Group,  3rd  edition) 

Airline  and  manufacturers  experience  in  developing  scheduled  maintenance  for 
new  aircraft  has  shown  that  more  efficient  programs  can  be  developed  through  the 
use  of  logical  decision  processes.  Historically,  the  initial  scheduled  maintenance 
tasks  and  intervals  have  been  specified  in  Maintenance  Review  Board  (MRB) 
Reports.  MSG-3  is  intended  to  facilitate  the  development  of  initial  scheduled 
maintenance.  The  remaining  maintenance,  that  is,  non-scheduled  or  nori-routine 
maintenance,  consists  of  maintenance  actions  to  correct  discrepancies  noted 
during  scheduled  maintenance  tasks,  other  non-scheduled  maintenance,  normal 
operation,  or  data  analysis.  This  report  addresses  the  development  of  scheduled 
maintenance  using  the  MSG-3  analysis  procedure. 


1 1.8.3. 1  Development  of  Scheduled  Maintenance 

The  objectives  of  efficient  aircraft  scheduled  maintenance 
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-  To  ensure  realization  of  the  inherent  safety  and  reliability  levels  of  the  aircraft. 

-  To  restore  safety  and  reliability  to  their  inherent  levels  when  deterioration  has 
occurred. 

-  To  obtain  the  information  necessary  for  design  improvement  of  those  items 
whose  inherent  reliability  proves  inadequate. 

-  To  accomplish  these  goals  at  a  minimum  total  cost,  including  maintenance 
costs  and  the  costs  of  resulting  failures. 

The  content  of  the  scheduled  maintenance  itself  consists  of  two  groups  of  tasks 
A  group  of  scheduled  tasks  to  be  accomplished  at  specified  intervals.  The 
objective  of  these  tasks  is  to  prevent  deterioration  of  the  inherent  safety  and 
reliability  levels  of  the  aircraft.  The  tasks  in  scheduled  maintenance  may  include: 

■  Lubrication/Servicing  (LU/SV) 

■  OperationalA/isual  Check  (OPA/C) 

■  Inspection/Functional  Check  (IN/FC) 

■  Restoration  (RS) 

■  Discard  (DS) 

■  A  group  of  non-scheduled  tasks  which  result  from 

■  The  scheduled  tasks  accomplished  at  specified  intervals 

■  Reports  of  malfunctions  (usually  originated  by  the  operating  crew) 

■  Data  analysis 

The  objective  of  these  non-scheduled  tasks  is  to  restore  the  aircraft  to  an 
acceptable  condition.  As  the  essence  of  automatic  logistics,  an  efficient  program  is 
one,  which  schedules  only  those  tasks  necessary  to  meet  the  stated  objectives.  It 
does  not  schedule  additional  tasks,  which  will  increase  maintenance  costs  without 
a  corresponding  increase  iri  reliability  protection. 

Scheduled  maintenance  will  be  developed  via  the  use  of  a  guided  logic  approach 
and  will  result  in  a  task-oriented  program.  The  logic’s  flow  of  analysis  is  failure- 
effect  oriented. 


11.8.3.2  Divisions  of  MSG-3  Document 

There  are  four  main  working  portions,  System/Powerplant,  including  components 
and  APU’s  (Assistant  Power  Unit),  Aircraft  Structures,  Zonal  Inspections,  and 
L/HIRF  (Lighting/High  Intensity  Radiated  Field),  in  the  MSG-3.  And  each  portion 
has  it  own  explanatory  material  and  decision  logic  diagram. 

Before  the  actual  MSG-3  logic  can  be  applied  to  an  item,  the  aircraft's  significant 
systems  and  components  must  be  identified.  Maintenance  Significant  Items  (MSI) 
are  items,  which  are  fulfilling  defined  selection  criteria  for  which  MSI  analyses  are 
established  at  the  highest  manageable  level.  The  MSI  selection  process  is 
described  below:  The  manufacturer  partitions  the  aircraft  into  major  functional 
areas;  ATA  Systems  and  Subsystems.  This  process  continues  until  all  on-aircraft 
replaceable  components  have  been  identified.  Then  using  a  top-down  approach  to 
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establish  the  list  of  items  to  which  the  MSI  selection  questions  will  be  applied.  MSI 
selection  questions  consist  of  these  four  quizzes: 

■  Could  failure  be  undetectable  or  not  likely  to  be  detected  by  the  operating 
crew  during  normal  duties? 

■  Could  failure  affect  safety  (on  ground  or  in  flight),  including 
safety/emergency  systems  or  equipment? 

■  Could  failure  have  significant  operational  impact? 

■  Could  failure  have  significant  economic  impact? 

As  long  as  one  of  the  above  four  is  answered  with  “yes”,  the  MSG-3  analysis  is 
necessary.  In  addition  the  highest  manageable  level  should  be  confirmed.  After  the 
MSI’s  have  been  selected,  the  following  must  be  identified  for  each  MSI: 

■  Function(s)  -  the  normal  characteristic  actions  of  an  item 

■  Functional  Failure(s)  -  Failure  of  an  item  to  perform  its  intended  function 
within  specified  limits 

■  Failure  Effect(s)  -  what  is  the  result  of  a  functional  failure 

■  Failure  Cause(s)  -  why  the  functional  failure  occurs 

Prior  to  applying  the  MSG-3  logic  diagram  to  an  item,  a  preliminary  work  sheet  will 
be  completed  that  clearly  defines  the  MSI,  its  function(s),  functional  failure(s), 
failure  effect(s),  failure  cause(s)  and  any  additional  data  pertinent  to  the  item. 


11.8.3.3  Logic  Diagram 

This  decision  logic  diagrams  (Figures  11.33  &  11.34)  are  especially  used  for 
analysis  of  system/powerplant  items.  The  logic  flow  is  designed  by  the  user  begins 
analysis  at  the  top  of  this  diagram  and  then  answer  “yes”  or  “no”  questions  will 
indicate  direction  of  the  flow.  There  are  two  levels  in  the  decision  logic: 

(1)  Level  1  (questions  1,  2,  3  and  4)  requires  the  evaluation  of  each 
FUNCTIONAL  FAILURE  for  determination  of  the  Failure  Effect  Category;  i.e., 
safety,  operational,  economic,  hidden  safety  or  hidden  non-safety. 

Level  2  (questions  5,  6,7,  8  and  9,  "A"  through  "F",  as  applicable)  then  takes  the 
FAILURE  CAUSE(S)  for  each  functional  failure  into  account  for  selecting  the 
specific  type  of  task(s). 

At  level  2,  the  task  selection  section,  paralleling  and  default  logic  have  been 
introduced. 
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Figure  11.33: 


System/Power  plant  Logic  Diagram  (from  Air  Transport 
Association  [2]) 
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Figure  11.34:  System/Power  plant  Logic  Diagram  (from  Air  Transport 

Association  [2]) 
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11.8.3.4  Task  Interval  Determinations 

It  is  also  a  part  of  the  MSG-3  Logic-Analysis,  the  MWG  (Maintenance  Working 
Group)  determines  the  interval  of  each  scheduled  maintenance  task  that  satisfies 
not  only  the  applicability  but  also  effectiveness  criteria.  The  MWGs  should  select 
the  most  appropriate  interval  for  each  maintenance  task  based  on  available  data 
and  good  engineering  judgment.  Here  are  some  sources  of  information  that  can 
provide  MWG  to  determine  the  most  appropriate  task  interval: 

■  Manufacturer’s  tests  and  technical  analysis 

■  Manufacturer’s  data  and/or  vendor  recommendations 

■  Customer  requirement 

■  Service  experience  gained  with  comparable  or  identical  components  and 
subsystems. 

■  Best  engineering  estimates 

In  the  recent  aviation  industry,  the  most  widely  used  task  interval  parameters, 
which  measure  the  exposure  to  the  condition  that  cause  the  failure  at  which  the 
task  is  directed  are: 

■  Calendar  time 

■  Flight  hours 

■  Flight  cycles 

■  Engine/APU  hours/cycles 

1 1 .8.4  Monitoring  the  health  of  the  airplane  engine 

Monitoring  the  health  of  the  airline  engine  fleets  is  a  critical  factor  that  can  have  a 
huge  impact  on  operational  viability  and  maintenance.  Real-time  information  must 
be  available  to  permit  the  successful  on-wing  management  of  engines  and  the 
planning  of  engine  removals.  With  current  engine  health  monitoring  and  trending 
technology,  engines  are  tracked  with  reference  to  manufacturers’ 
recommendations.  Usually,  this  task  has  to  be  accomplished  by  specialist 
engineers  in  airline  engineering  departments  or,  in  the  case  of  contracted  IVIROs 
(Maintenance,  Repair,  Overhaul),  by  other  nominated  staff.  Such  engineers  use  all 
available  information  to  build  up  a  picture  of  engine  condition  and  schedule  the 
maintenance  to  be  performed,  as  their  experience  dictates.  The  decision  to 
perform  maintenance  on-wing  requires  a  very  accurate  understanding  of  an 
engine’s  specific  deterioration  and  it  will  be  based  on  an  assessment  of  online 
updates  of  engine  condition  monitoring  data,  together  with  any  supplemental 
information  provided  by  maintenance  personnel.  The  possibility  of  keeping  an 
engine  on-wing  can  offer  significant  benefits  to  both  maintenance  providers  and 
airline  operators.  It  can  save  a  time-consuming  engine  change,  the  cost  of  leasing 
a  spare  engine  and  the  cost  of  the  unplanned  engine  shop  visit.  Any  on-wing 
maintenance  action  prescribed  by  engineers  should  achieve  the  desired  results 
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without  causing  any  additional  operational  disruption,  thereby  avoiding  further 
financial  repercussions. 


Engfne  health  monitoring  system 


•  iTCl-lkM 
#Gompkrt&  data  sets 
•all  kMe  of  madifos 


WM>  monitoring  Ilk 
DooHon  making  tail 
Engl  n»  float 
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Figure  11.35:  Engine  health  monitoring  system  (from  William  Gizzi  [3]) 

In  the  recent  marketplace,  some  commercial  engine  health  monitoring  and 
decision  support  system  can  fulfill  the  demand  of  automated  trending  and  fault 
pattern  analysis.  This  kind  of  system  procures  its  data  from  an  engine's  existing 
sensor  and  FADEC  (Full  Authority  Digital  Engine  Control)  equipment,  thereby 
introducing  no  additional  equipment  or  infrastructure  costs.  Its  pacemaker 
technology  has  “self-learning”  artificial  intelligence,  which  permits  it  to  build  a 
baseline  model  of  each  monitored  engine,  regardless  of  its  type  or  its  manufacturer. 
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11.9  Appendix:  7  -Industrial  logistics  applications:  Penske  case 

11.9.1  Introduction 

1 1 .9.2  Mission  of  Penske  Corp. 

11.9.3  Maintenance  program 

1 1 .9.3.1  Tasks  and  maintenance  group 

11.9.3.2  Maintenance  process 

11.9.3.3  Maintenance  program 

11.9.4  Performance  and  failure  analysis 

11.9.4.1  Maintenance  performance  measure 

1 1 .9.4.2  Utilizing  failure  analysis  to  solve  problems 

11.9.4.3  Supplier  measures 

1 1 .9.5  Application  of  Penske  logistics  and  supply  chain  solution 

11.9.5.1  Ford  case 

11.9.5.1  Mission  foods  case 

11.9.5.1  Whirlpool  case 
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1 1.9.1  Introduction 

Recent  announcement  of  retail  giant,  Wal-mart’s  push  for  radio-frequency 
identification  (RFID)  labels  for  its  top  100  suppliers  by  January  2005  attracts  much 
attention  in  the  areas  of  logistics  and  supply  chain  management.  It  was  only  20 
years  since  Wal-mart  required  barcode  for  its  vendors.  Though  Wal-Mart  has  not 
yet  specified  what  its  mandate  will  actually  entail  in  terms  of  compliance,  vendors 
have  little  doubt  that  the  retailer  is  serious  about  meeting  its  deadline.  Many 
logistics  providers,  third  party  logistics  (3PL)  and  fourth  party  logistics  (4PL) 
companies  need  to  prepare  for  the  technology  changes  in  advance. 

Penske,  one  of  the  largest  logistics  company  in  US,  provides  complete  fleet 
management  services  including  full  service  leasing,  logistics,  truck  rentals  for 
families  and  business,  used  trucks  for  sale  and  fleet  services  for  utility  and  transit 
companies  and  municipalities.  Penske  can  help  maximize  the  effectiveness  of 
transportation  and  distribution  with  proven  services.  They  provide  full-service 
leasing,  contract  maintenance,  supply  chain  management  (SCM)  &  logistics  and 
truck  rentals. 

In  this  appendix,  the  main  characteristics  of  logistics  and  SCM  in  Penske  are 
demonstrated.  Also,  the  maintenance  process  and  procedures  are  investigated  in 
order  to  apply  the  process  in  the  other  public  sectors. 


11.9.2  Mission  of  Penske  Corp. 

The  organization  of  Penske  covers  transportation  and  logistics,  retail  automotive, 
automotive  performance,  and  transportation  manufacturing.  The  details  of  major 
functional  areas  or  missions  are  summarized  as  the  following. 

•  Truck  leasing:  full  service  leasing,  contract  maintenance,  logistics  and  SCM, 
commercial  and  consumer  truck  rental,  energy  and  telecom,  and  automotive 
delivery. 

•  Full  service  leasing:  complete  fleet  service,  rental  vehicles,  customer- 
engineered  vehicles,  comprehensive  preventive  maintenance  program. 

•  Logistics:  For  Penske  logistics  area,  there  are  114  major  customers 
operated  by  13,500  vehicles  including  GM,  Ford,  Toyota  etc. 

•  Rental  automotive  (Penske  auto  group,  United  auto  group:  126  franchises, 
30+  brands) 

•  Automotive  performance  (IRL,  NASCAR) 

•  Transportation  manufacturing  (Truck-Lite,  DAVCO  mfg) 

•  IRL:  Indy  Racing  League 
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11.9.3  Maintenance  program 


1 1. 9.3.1  Tasks  and  maintenance  group 

As  there  are  more  than  200,000  vehicles  in  the  Penske,  maintenance  is  crucial  for 
its  competitive  excellence.  The  company  wants  to  maximize  uptime  through  six 
sigma  approach  to  maintaining  the  broadest  range  of  vehicles.  Major  tasks  for 
maintenance  are  vehicle  application,  vehicle  purchasing,  administration, 
maintenance  operation,  and  systems  analysis.  The  organization  for  the 
maintenance  operation  consists  of  2  vice  presidents,  6  area  maintenance 
managers,  83  district  service  managers,  218  branch  service  managers,  382 
maintenance  supervisors,  4000+  technicians,  1 150+  customer  service  rep’s. 


1 1. 9.3.2  Maintenance  process 


Maintenance  process  is  consisted  of  data  capture,  analysis,  feedback,  and 
improvement.  The  whole  process  is  interrelated  with  each  other  as  shown  in  Figure 


11.35. 
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Figure  11.36:  Maintenance  process  in  Penske 
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11.9.3.3  Maintenance  program 

Maintenance  programs  are  composed  of  basic  preventive  maintenance,  fuel 
service,  oil  analysis,  coolant  analysis,  tires,  and  batteries.  The  standards  for  the 
maintenance  are  shown  as  the  following. 

1)  Preventive  maintenance 


Type  of  vehicle 

Miles 

Days 

Heavy  duty  diesel 

30,000  or 

120 

And  150,000 
or 

455 

Midrange  diesel 

20,000  or 

180 

Light  duty  diesel 

6,000  or 

180 

All 

60,000  or 

485 

Medium  duty  gas 

8,000  or 

90 

Light  duty  gas 

6,000  or 

90 

All  non-reefer  trailers 

— 

180 

Reefer  trailers 

— 

90 

Refrigeration  units-Tractors 

750  hours  or 

90 

Refrigeration  units-Trailers 

4,000  hours  or 

720 

Refrigeration  units-T rucks 

1 ,500  hours  or 

360 

Table  11.8:  Preventive  maintenance  schedule  (Source:  Douglas,  2003) 

2)  Oil  analysis  program 

The  advantage  of  oil  analysis  program  is  downtime  reduction,  identification  of 
premature  failure,  cost/mile  reduction,  and  management  tool.  The  details  of  the 
program  are  as  follows. 

•  Sample  at  each  inspection  period 

•  Corrective  action 

•  Maintenance  feedback 

•  Monthly  location  reports 

3)  Coolant  analysis 

•  Sample  annually  (PH  level,  Alkalinity,  Freeze  point,  Nitrate  level, 
Contamination,  Corrosive  inhibitors) 

•  Action  gram  for  corrective  action 

•  Maintenance  feedback 
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11.9.3.4  Performance  and  failure  analysis 


11.9.3.4.1  Maintenance  performance  measures 

-  Engine  analysis:  %  of  engine  cost  (power  plant,  fuel  system,  cooling 
system,  engine,  air  intake  system,  exhaust  system) 

-  Key  component  analysis 

o  Chassis  (brakes,  front  axle,  suspension) 

o  Electrical  (lighting,  charging) 

o  Engine  (cooling,  power  plant,  fuel,  exhaust) 

o  Drive  train  (rear  axle,  suspension,  main  std  transmission) 

o  Body  &  trailer 

o  Refrigeration 

o  Accessories 


11.9.3.4.2  Utilizing  failure  analysis  to  solve  problems 

-  Calculate  ‘rate  of  failure’  for  each  part 

-  Tracking  incidents  over  5  years 

-  Drill  down  incidents  by  parts  (See  Figure  6.2) 

-  Manufacturer  comparison  for  first  year  incidents 


Component  analysis  report 
(TANDEM  AXLE  DIESEL  TEACTORS) 


Detailed  analysis 


Svstem/part  description  (Kate  ot  tanure  (%)) 


System  description  System 
Air  conditioner  group 


36.2 

8.3 


Part 


Compressor 


Detailed  analysis  of 
“Switches” 


1.1 

17.2 

3.7 


0.2 


Figure  11.37:  Drill  down  approach  for  failure  analysis 
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1 1 .9.4  Supplier  measures 

(1)  Supplier  Measurement  Criteria 

-  Product  support 

-  Teamwork 

-  Service  support 

-  Communication 

(2)  Based  on  the  above  criteria,  top  performing  vendors  are  recognized  on  vendor 
conference  in  the  following  areas. 

-  OEM 
Powertrain 
Bodies/trailers 

-  Accessories 

-  Tires 


1 1 .9.5  Application  of  Penske  logistics  and  supply  chain  solution 

The  breadth  of  Penske’s  experience  is  reflected  through  their  customers.  Across  a 
broad  range  of  industries,  geographies  and  services,  Penske  provides  her 
customers  with  the  highest  possible  value  through  our  design,  technology  and 
operational  execution.  Success  stories  of  Ford,  Mission  foods,  and  Whirlpool  cases 
are  summarized  as  the  following. 

1 1.9.5. 1  Ford  case 

Penske  partnered  with  Ford  on  several  Six  Sigma  quality  projects. 

Reducing  inbound  carrier  discrepancies:  analyzing  data  on  part  discrepancies 
and  premium  costs,  determining  the  root  causes  for  these  defects  and  then 
identifying  solutions.  ->  a  43  percent  reduction  of  discrepancies  and  total 
savings  of  $970,000  for  the  year  2001 . 

The  Assembly  Matrix  Project  used  Six  Sigma  methodologies  to  reduce 
deviations  from  required  time  on  expedited  shipments.  ->  reduced  deviation 
costs  by  78  percent,  saving  Ford  $220,000. 

Parts  deviations  due  to  shipment  overages.  This  project  revealed  that  15 
percent  of  all  parts  deviated  from  plant  requirements  due  to  overages,  causing 
additional  transportation  costs  and  productivity  losses.  Overages  were  reduced 
by  50  percent  and  with  fewer  overages  to  resolve.  ->  $400,000  in  savings  for 
Ford. 
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11.9.5.2  Mission  foods  case 

-  A  producer  of  tortillas  and  snacks 

-  By  applying  Six  Sigma  quality  tools,  Penske  Logistics  was  able  to  reduce 
transportation  costs  for  the  plant  by  1 1  percent. 

-  Penske  delivered  a  6.5  percent  cost  reduction  per  pound  in  transportation,  and 
has  consistently  achieved  over  99  percent  on-time  delivery  at  all  10  of  its 
manufacturing  plants  in  the  United  States. 


11.9.5.3  Whirlpool  case 

-  Penske  helped  Whirlpool  redesign  its  network  to  deliver  consistent,  high 
quality  service  nationwide,  including  all  trade  partner  channels  while  providing 
them  with  the  tools  to  measure  performance  in  a  real-time  environment. 

-  Engineered  an  integrated  technology  solution  to  provide  fast  and  accurate 
information  to  speed  up  the  cash-to-cash  cycle  and  improve  overall  customer 
service. 

-  Also,  established  a  joint  process  to  introduce  third-party  business  into  the 
network,  so  Whirlpool’s  supply-chain  operation  can  leverage  other  business  to 
reduce  its  network  costs. 
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11.10.1  Introduction 

Telematics  is  often  considered  a  cross  between  telecommunications  and  computer 
systems.  This  includes  dial-up  service  to  the  Internet  as  well  as  all  types  of 
networks  that  rely  on  a  telecommunications  system  to  transport  data.  For 
automobiles  a  telematics  system  consists  of  putting  a  computer,  a  wireless 
connection  to  either  an  operator  or  data  services  like  the  Internet  and  a  global 
positioning  system  (GPS)  into  a  car,  and  becomes  known  as  Automotive 
Telematics.  The  term  is  further  evolving  to  include  a  wide  range  of 
telecommunication  functions  that  originate  or  end  inside  automobiles.  Telematics  is 
also  being  considered  for  monitoring  purposes,  but  is  rarely  referred  to  in  any 
context  beside  automobiles. 


11.10.2  Automotive  Telematics 

It  is  important  to  understand  the  definition  of  what  constitutes  a  telematics-enabled 
auto.  From  a  hardware  standpoint,  Telematics  Research  Group  uses  the  following 
telematics  definition: 

□  A  telematics-enabled  auto  has  2-way  communications 

□  A  telematics-enabled  auto  has  a  location  sensing  device 

□  A  telematics-enabled  auto  has  a  control  unit  that  is  interfaced  to  the  auto’s 
electronic  system 

These  three  requirements  define  the  basic  capabilities  of  a  telematics  system. 
There  are  often  many  additional  features  and  capabilities  in  telematics  systems. 
The  next  table  shows  the  telematics  definition  in  more  detail. 


Must  Have: 

Main  Approaches 

May  Have: 

2-\\  a> 

communications 

•  Lm bedded  cell  phone 

•  Integrated  driver  cell  phone 

•  1  elematics  service  monitoring 

•  Remote  auto  function  control 

•  Remote  auto  diagnostics 

•  Automatic  collision  notification 

•  c  rash  e\  ent  data  recorder 

•  Bluetooth  communication 

•  Speech  user  interface 

•  ( )n- board  or  off-board  na\  igalion 

I  ocation 
technolog) 

•  GPS  receiver 

•  C  ell  phone  location  technology 

(  ontrol  unit  with 
auto  electronics 
interface 

•  Imbedded  telematics  system  for  safety 
&  security  applications 

•  Hands-free  cell  phone-radio  integration 

•  Navigation-cell  phone-radio  integration 

Table  1 1 .9:  Detail  Definition  of  Telematics 


From  a  functional  standpoint,  telematics  technologies  will  become  increasingly 
necessary  to  support  the  various  capabilities  of  the  automobile  in  the  future.  This  is 
particularly  true  as  vehicles  continue  their  transition  from  analog  to  digital 
technologies.  With  this  in  mind,  Telematics  Research  Group  sees  telematics 
evolving  to  fulfill  the  following  functional  requirements  within  the  auto: 
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•  Enabling  Technology  -  For  mobile  communications,  vehicle 
diagnostics/prognostics,  safety  and  security,  electronic  toll  collection,  traffic 
management,  event  data  recorders,  and  driver  information  systems. 

•  Services  Platform  -  For  content  and  information  services  that  offer  value  to 
the  customer  including  traffic  reports,  routing,  point-of-interest  (POI), 
customized  voice  portals,  concierge,  etc. 

Automotive  telematics  systems  will  become  quite  complex  because  they  involve  so 
many  different  industries  that  make  up  the  hardware  requirements:  computer, 
semiconductor,  communications,  consumer  electronics  and  automotive  industry. 
Furthermore,  telematics  will  span  many  content  and  services  industries  such  as 
communications,  travel/mobility,  weather  and  traffic  information,  entertainment, 
Internet  and  location-based  services. 


1 1 .1 0.3  Technologies  in  Automotive  Telematics 

11.10.3.1  Technologies  for  Telematics 

Computer,  communications  and  many  other  technology  advances  will  have  a 
profound  impact  on  the  telematics  industry.  Hence  it  is  useful  to  understand 
technology  advances  and  trends.  The  following  figure  is  an  overview  of  all  the 
technologies  that  are  impacting  the  telematics  industry. 
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Figure  11.39:  Technologies  in  the  Telematics  Industry 


■  Telematics  Control  Unit 

The  telematics  control  unit  (TCU)  is  an  embedded  computer  designed  for 
telematics  functions.  The  user  interface  or  HMI  (human  machine  interface)  as  it  is 
often  called,  may  use  the  audio  capabilities  of  the  car  radio  and  may  have  a 
display  unit.  Displays  are  primarily  used  in  telematics  systems  that  include 
navigation  systems. 

Telematics  systems  use  a  thin-client  architecture  for  two  reasons — achieve  low 
manufacturing  cost  and  to  minimize  technology  obsolescence.  Thin-client 
architecture  means  that  the  TCU  has  limited  capabilities  and  limited  client 
applications.  Instead  most  applications  need  help  from  a  remote  server,  which  is 
called  a  client/server  application. 

Currently,  the  TCU  has  limited  hardware  and  software  capabilities,  but  this  will 
grow  substantially,  based  on  normal  computer  technology  improvements.  To 
minimize  future  hardware  obsolescence  and  simplify  repair,  TCU  designs  will 
become  modular  and  will  have  field  upgradeable  subsystems. 

■  Human  Machine  Interface 

The  HMI  (human  machine  interface)  depends  on  the  hardware  interface.  The  trend 
is  towards  speech  recognition  software  as  command  input  with  text-to-speech 
output  via  the  audio  system. 

Large  color  display-based  user  interfaces  are  falling  out  of  favor  due  to  driver 
distraction  issues  but  are  still  necessary  for  many  types  of  output.  These  display- 
based  interfaces  will  increasingly  be  supplemented  by  auxiliary  displays  and  driver 
information  systems  in  or  around  the  instrument  cluster. 
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■  Electronic  Technology 

X-by-wire  or  drive-by-wire  is  an  electronic  technology  that  replaces  the  auto’s 
mechanical  and  hydraulic  systems.  X-by-wire  functionality  will  be  used  with 
intelligent  vehicles  systems  and  both  will  gain  capabilities  from  each  other’s 
functionality.  Intelligent  vehicle  functions  are  advanced  capabilities  that  are  added 
to  traditional  auto  functions.  Most  intelligent  vehicle  systems  are  based  on  the  use 
of  visual  sensors  coupled  with  vast  computing  capabilities  that  recognize  sensor 
inputs.  The  sensor  information  is  used  to  notify  the  driver  about  potential  danger  or 
help  the  driver  when  imminent  danger  occurs. 

■  Event  Data  Recorders 

Limited  crash  event  data  recorders  (EDRs)  were  introduced  when  airbags  systems 
appeared  to  gather  data  on  airbag  operation.  GM  introduced  EDRs  with  pre-crash 
data  storage  in  1999  auto  models.  The  data  from  these  crash  recorders  are 
manually  retrieved  and  downloaded  to  laptop  PCs.  The  data  are  by  accident 
investigators,  auto  manufacturers  and  government  agencies.  There  are  federal 
initiatives  to  increase  the  use  of  crash  EDRs.  It  is  likely  that  crash  EDRs  will  be 
mandated  for  use  in  all  autos  in  the  future. 

Future  telematics  systems  will  integrate  the  crash  EDR  and  will  automatically 
transmit  crash  data  to  a  central  location  momentarily  after  the  crash  occurred.  GM 
is  expected  to  be  a  leader  in  using  crash  EDR  that  automatically  transmits  real 
time  crash  data  to  a  central  location.  As  real-time  crash  EDR  information  gets 
distributed  after  2005,  the  U.S.  is  likely  to  become  the  technology  leader  with 
positive  impact  for  most  commuters. 

■  Remote  Diagnostics 

Remote  diagnostics  may  be  the  most  important  telematics  application  for  the  auto 
manufacturers.  The  applications  that  can  be  built  on  top  of  regular  remote 
diagnostics  from  millions  of  cars  are  likely  to  save  the  auto  manufacturers  lots  of 
money.  Remote  diagnostics  have  potential  savings  in  operational  costs,  warranty 
costs  and  design  improvements.  User-initiated  remote  diagnostics  that  will  save 
the  auto  owner  repair  and  maintenance  expenditure  is  also  expected  with 
considerable  positive  CRM  impact. 

■  Real  Time  Traffic  Data 

Real  time  traffic  data  may  be  the  most  valuable  telematics  content.  Japan  and  the 
European  countries  are  further  along  in  collecting  and  distributing  traffic  condition 
data  than  the  U.S.  The  European  traffic  data  are  broadcast  via  car  radios  using 
special  frequency  bands.  Japan  has  nearly  6M  VICS  (Vehicle  Information  and 
Communication  System)  receivers  that  receive  traffic  information  via  FM  radio,  RF 
beacons  and  infrared  transmitters.  The  traffic  data  collection  industry  is  improving 
in  the  U.S.  Future  integration  with  telematics  systems  will  greatly  improve  in  the 
next  decade. 


154 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  1 


11.10.3.2  Emerging  Technologies  of  Telematics  Solutions 

Accenture  Technology  Labs  predicts  that  the  emerging  technologies  that  can  be 
used  to  create  these  cutting-edge  telematics  solutions  will  achieve  widespread 
adoption  within  the  next  three  to  five  years.  Several  technology  trends  are  shaping 
the  future  of  telematics,  and  OEMs  need  to  consider  various  factors  that  may 
prevent  implementation  of  a  successful  telematics  strategy. 

■  Software  Platforms 

To  date,  telematics  systems  have  been  mainly  purpose-built,  meaning  that 
everything  from  the  system's  functionality  to  its  hardware  and  software  to  its  user 
interface  is  designed  to  serve  a  specific  function.  Ironically,  computer  systems 
have  become  increasingly  open,  generic  and  flexible.  OEMs  will  need  to  build 
telematics  platforms  that  bridge  these  two  worlds  of  function  and  flexibility.  In 
addition,  data  warehouses,  along  with  real-time  analytics  capabilities,  will  be 
necessary  to  capture  and  exploit  the  data  generated  by  vehicles  and  their 
telematics  applications. 

■  Cellular  and  Satellite  Networking 

There  are  two  ways  to  provide  cellular  networking  in  a  vehicle.  One  is  through  the 
use  of  cellular  models,  which  can  be  embedded  directly  into  the  vehicle. 
Alternatively,  data  connections  can  be  established  between  a  user’s  mobile  phone 
and  the  vehicles’  telematics  system. 

As  newer  cellular  standards  emerge,  such  as  2.5G  and  3G  networks,  OEMs  will  be 
hard  pressed  to  choose  a  potential  cellular  partner  and  decide  which  technologies 
to  embed  in  their  vehicles.  Rapid  advances  in  wireless  technologies  far  outpace 
the  lifespan  of  a  vehicle.  But,  wireless  is  not  the  only  option  OEMs  have  for  data 
communications.  Satellite  communication  will  continue  to  be  more  advantageous 
for  navigation,  safety  and  locational  services  as  they  require  more  reliable 
positioning  capabilities.  In  addition,  satellites  will  continue  to  be  utilized  for 
diagnostic  applications,  which  require  a  slow  and  steady  transfer  of  real-time 
information  from  the  vehicle  to  the  OEM  or  dealer. 

■  Wireless  Local  Area  Networks  and  Bluetooth 

It  is  expected  that  Wireless  Local  Area  Networks  (WLANs)  -  with  their  high 
bandwidth,  open  standards  and  relatively  low  cost  -  will  co-exist  with  Bluetooth 
technologies,  which  allow  in  -  vehicle  systems  to  communicate  with  one  another. 
When  this  occurs,  vehicular  systems  will  no  longer  be  self-contained.  Rather,  they 
will  become  part  of  larger  Personal  Area  Networks  (PANs),  fully  networked  with 
surrounding  devices  and  systems  and  synchronized  with  home  and  office 
computers.  Furthermore,  evolving  peer-to-peer  networks  will  create  opportunities 
for  vehicle-to-vehicle  applications,  including  real-time  traffic  reporting  and  real-time 
performance  evaluations  for  the  same  make  and  model  vehicle  -  all  reported  from 
one  automobile  to  another. 
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■  In-Vehicle  Architecture 

System  designers  are  faced  with  hard  choices  related  to  the  most  appropriate  in- 
vehicle  architecture.  They  must  be  able  to  effectively  manage  a  wide  array  of 
sensors,  vehicle  and  communications  systems.  Two  leading  contenders  for  vehicle 
architecture  include  Microsoft’s  Windows  CE  for  Automobile  and  the  Open 
Services  Gateway  Initiative  (OSGI)  standard.  A  proliferation  of  embedded 
operating  systems  is  gaining  traction  among  OEMs;  some  of  the  options  include 
embedded  Linux,  QNX  and  VxWorks  (real-time  OS  for  the  embedded  application 
development).  Because  the  market  is  still  emerging,  providers  should  create  an 
underlying,  back-en  architecture  that  is  able  to  accommodate  multiple  vehicle 
architectures. 


11.10.4  Telematics  in  Location-Based  Service 

Vehicles  are  attractive  platforms  for  location-based  services.  They  are  inherently 
mobile;  and  many  services  of  interest  to  their  owners,  drivers,  manufacturers  and 
even  governments  can  be  enhanced  by  knowing  where  the  vehicle  is  and  being 
able  to  communicate  with  it.  This  combination  of  wireless  communication  and 
location  awareness  will  be  the  foundation  of  a  wide  range  of  products  and  services 
during  the  next  decade. 


Figure  11.40:  Telematics  Navigation  Tool 


■  Location  Needs  Communication  and  Context 

Knowledge  of  a  vehicle’s  location  is  useful,  but  not  sufficient  to  deliver  the  highest 
value  services.  It  must  be  augmented  with  two  things:  bidirectional  communication 
and  contextual  information,  such  as  the  driver’s  preferences  and  the  state  of  the 
vehicle.  By  2007,  it  is  expected  that  45  percent  of  new  vehicles  include  a  built-in 
cellular  modem  dedicated  to  telematic  tasks. 


■  Application  Opportunities 

In  the  medium  three-to-five-year  time  span,  it  is  expected  that  the  technologies 
such  as  Bluetooth  to  enable  a  tighter  integration  between  vehicle  systems  and 
personal  devices  such  as  phones,  further  increasing  the  sophistication  of  potential 
applications.  A  small  selection  of  the  potential  location-based  (augment  location 
knowledge  with  context  and  bidirectional  communication)  vehicle  applications 
includes: 
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□  Finding  places  and  services:  When  it  is  possible  to  augment  location 
knowledge  with  context  and  bidirectional  communication,  such  applications 
can  provide  greater  value  to  both  customers  and  suppliers.  For  example, 
“find  me  a  petrol  station”  can  become  “find  me  the  cheapest  petrol  station 
that  is  in  the  general  direction  in  which  I’m  traveling  and  that  I  can  reach  on 
the  fuel  remaining  in  the  tank." 

□  Driver  information:  Basic  driver  information  provided  by  several  systems, 
such  as  phone  network,  in-car  navigation  systems  and  dedicated  terminals 
have  the  potential  to  become  much  more  sophisticated.  For  example, 
providing  dynamic  traffic  and  weather  dependent  routing. 

□  Safety  and  security:  Accident  support  systems  can  already  call  for  help 
when  events  such  as  airbag  deployment  are  detected.  However,  there  will 
be  considerable  further  potential  in  the  area.  Combination  of  communication 
and  location  could  provide  dynamic  safety  information. 

□  Entertainment,  Parking  services,  Pollution  management,  and  so  on. 

In  the  longer  term,  location-aware,  network-enabled,  intelligent  vehicles  could 
suggest  more  radical  changes  to  some  business  models.  For  example, 

□  Insurance  could  be  charged  on  the  basis  of  continuous  risk  assessment 
based  on  factors  such  as  the  vehicle’s  location,  speed  and  use. 

□  Logistics  could  be  based  on  dynamic  rendezvous  rather  than  static  depots. 
Cargo  vehicles  could  meet  and  exchange  contents  dynamically,  rather  than 
a  fixed  locations. 

□  If  cars  can  find  the  location  of  services  and  direct  drivers  to  them,  products 
such  as  petrol  might  be  supplied  from  mobile  tankers  rather  than  fixed 
stations,  allowing  suppliers  greater  flexibility  and  reduced  real  estate  costs. 


11.10.4.1  Technologies  for  Wireless  Location-Based  Services 

Three  key  technologies  exist  to  deliver  location-based  services  over  mobile 
network:  Cell-ID;  enhanced  observed  time  difference  (E-OTD);  and  assisted  Global 
Positioning  System  (A-GPS). 
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Figure  11.41:  Wireless  Infrastructure  in  Automotive  Telematics 


■  Cell-ID 

Cell-ID  is  the  most  basic  location-based  technology.  Using  it,  a  mobile-network 
operator  can  determine  a  mobile-terminal  user’s  location  by  identifying  the  cell  site 
(antenna  location)  from  which  the  user  is  accessing  the  network. 

The  accuracy  of  this  technology  depends  on  the  density  of  the  cell  sites.  In  urban 
areas,  cell  sites  are  typically  densely  populated;  this  often  gives  results  accurate  to 
within  50  and  250  meters.  In  rural  areas,  however,  cell  sites  can  have  a  radius  of 
more  than  20  kilometers. 


■  Enhanced  Observed  Time  Difference 

It  measures  how  long  it  takes  radio  waves  from  two  different  base  stations  to  reach 
a  user’s  mobile  terminal,  and  then  locates  that  terminal  using  triangulation. 

E-OTD  provides  theoretical  accuracy  of  between  30  and  50  meters,  but  in  many 
cases  its  real-world  accuracy  may  be  less  than  this.  Nevertheless,  E-OTD  is  a 
much  more  reliable  indicator  of  location  than  Cell-ID. 


A  similar  technology,  known  as  observed  time  difference  of  arrival  (OTDOA),  will 
be  deployed  in  third-generation  (3G)  mobile  networks,  for  which  location-based 
services  are  considered  key  deliverables. 

■  Assisted  Global  Positioning  System 

A-GPS  is  a  popular  location-based  technology  for  use  on  code  division  multiple 
access  (CDMA)  networks.  It  combines  element  of  the  Global  Positioning  System 
(GPS)  with  wireless-network  capabilities. 
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As  with  GPS,  A-GPS  requires  the  mobile  terminal  to  see  the  location  satellites. 
However,  a  terminal  cannot  do  so  when  inside  a  building  or  in  some  dense  urban 
areas;  in  these  case,  the  solution  has  to  use  cell-site  triangulation  as  the  sole 
means  of  determining  location. 

Like  E-OTD,  A-GPS  capability  requires  extensive  upgrades  to  network 
infrastructure  and  new  mobile  terminals. 

■  Associated  Technologies 


□  Short  Message  Service:  The  short  message  service  (SMS)  enables  up  to 
160  characters  of  text  or  140  bytes  of  information  to  be  sent  and  received. 
SMS  technology  has  been  used  in  early  location-based  applications.  By 
connecting  a  GPS  receiver  to  an  SMS-enabled  mobile  terminal  (module), 
location  information  can  be  transmitted  to  the  service  host. 

□  General  Packet  Radio  Service:  General  packet  radio  service  (GPRS)  is  a 
wireless  packet-based  data  bearer  that  provides  an  “always-connected 
environment.  GPRS’s  always-connected  state  makes  it  an  important 
technology  for  location-based  services  over  GPRS  for  a  rich  end-user 
experience. 

□  Bluetooth  and  Wide  Fidelity:  Bluetooth,  itself,  is  a  short-range  wireless 
communication  technology  that  expected  to  be  integrated  into  a  wide  range 
of  wireless  devices.  As  a  result,  Bluetooth  may  lead  to  easier  integration 
between  devices.  Blutooth  and  wide  fidelity  (WiFi)  are  not  intended  to 
operate  as  positioning  technologies,  but  enable  location  in  urban  and  indoor 
area.  Therefore,  they  complement  other  positioning  technologies  and 
increase  accuracy.  They  require  dense,  fixed  infrastructure  and  are  best 
suited  for  “hot  spots,”  that  is,  busy  area  where  mobile  device  owners  will 
congregate. 

To  date,  the  delivery  of  most  wireless  telematic  services  has  been  relatively  crude, 
using  either  basic  Cell-1  D  technology  or  GPS  in  conjunction  with  SMS. 

One  of  the  most  common  uses  of  Cell-ID  is  to  provide  traffic  information.  Most 
mobile-network  operators  enable  users  to  dial  a  short  code  on  their  mobile  terminal 
to  hear  the  latest  traffic  reports  By  determining  the  user’s  location  using  Cell-ID, 
operators  can  deliver  traffic  information  that  is  always  relevant. 

Use  of  GPS  in  conjunction  with  SMS  has  largely  been  limited  to  vertical-market 
applications  where  the  productivity,  customer  service,  security  and  other  benefits 
justify  the  installation  and  deployment  costs.  Typically,  a  GPS  receiver  is 
connected  to  a  dedicated  mobile  terminal  to  enable  transmission  of  highly  accurate 
location-based  information. 


11.10.5  Telematics  &  Diagnostics 

Remote  vehicle  diagnostics  (RVD)  is  gradually  emerging  as  a  potentially  inevitable 
next  step  in  the  technological  progression  of  the  automotive  industry,  with  the 
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promise  of  reduced  outlay  on  warranty,  product  development  and  marketing  acting 
as  a  compelling  value  proposition. 

Further  benefits  of  the  emerging  RVD  technology  will  be  manifested  in  the  creation 
of  competitive  advantage  through  product  differentiation  and  the  ability  to  provide 
improved  after-sales  service  and  support  to  customers. 

The  advent  of  RVD  will  present  vehicle  manufacturers  with  the  opportunity  to  step 
into  the  middle  of  their  distribution  and  after-sales  value  chain,  thus  developing 
closer  relationships  with  their  customer  base.  Automotive  manufacturers’  retention 
of  control  over  their  after-sales  service  value  chain  is  of  strategic  importance  in 
view  of  the  implementation  of  the  new  competition  laws  in  Europe. 

Apart  from  the  benefits  of  remote  diagnostics  for  passenger  vehicle  owners,  the 
technology  holds  tremendous  potential  for  cost-savings  and  process  improvements 
for  fleet  owners  and  vehicle  manufacturers. 

However,  due  to  the  technology’s  nascence,  vehicle  manufacturers  are  cautious  to 
announce  ambitious  plans  concerning  the  introduction  of  RVD  and  associated 
services.  A  number  of  technical  and  commercial  issues  such  as  prohibitively  high 
infrastructure  costs,  the  management  of  technological  obsolescence  of  component 
technologies  and  limited  bandwidth,  remain  unresolved  and  must  be  addressed  to 
enable  the  technology  to  fully  evolve  and  flourish. 

The  nature  of  the  remote  diagnostics  service  is  expected  to  evolve  from  passive 
and  periodic  diagnostics  to  vehicle-initiated  fault  notification  and  prognostics. 
Initially  launched  as  a  read-only  option,  where  diagnostic  trouble  codes  are 
deciphered  by  data  center  staff,  it  is  believed  that  the  service  will  make  its  debut  in 
top-of-the-range  vehicles  in  the  luxury  and  executive  segment  vehicles. 

The  simultaneous  introduction  by  different  manufacturers  -  such  as  BMW,  Fiat, 
Volvo,  and  PSA  -  and  the  benefits  of  the  quality  of  the  service  are  likely  to  drive  the 
market  penetration  in  these  vehicle  segments  from  2003  onwards.  Vehicle 
manufacturers  are  then  gradually  expected  to  introduce  the  service  between  2004 
and  2005  in  the  upper-medium  vehicle  segment  as  an  optional  feature. 

Across  lower  segment  vehicles,  RVD  will  be  available  only  as  an  optional  feature 
over  the  forecast  period,  and  installations  will  depend  on  the  attractiveness  of  the 
overall  package  offered  to  the  customer. 

Remote  diagnostics  is  not  likely  to  be  introduced  on  its  own,  but  is  likely  to  be 
bundled  in  a  package  along  with  other  telematics  services.  As  a  result,  even  on  the 
hardware  front,  vehicle  manufacturers  are  expected  to  use  the  telematics  unit 
installed  in  the  vehicle  to  perform  the  necessary  computations  and  communication 
for  the  remote  diagnostics  services  as  well. 
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Figure  11.42:  Remote  Vehicle  Diagnostics  Telematics  Service  Delivery 

Network 


■  Remote  Diagnostics 

□  Remote  Diagnostics  is  about  sending  real  time  vehicle  data  to  the 
Telematics  Service  Provider  continuously,  so  efficient  vehicle  monitoring 
can  be  done. 

□  The  TSP  analyses  these  data  to  make  sure  vehicle  are  in  the  good 
condition,  else  an  automated  maintenance  and  repair  report  will  be  issued. 

□  Vehicle  Parameters:  breaks,  suspension,  oil  and  other  fluid  levels,  steering, 
air  conditioning,  engine,  lights  and  exhaust,  tire  pressure,  coolant,  and  so  on. 

■  Controller  Area  Network  (CAN) 

□  Collect  vehicle  data  from  CAN  nodes  (e.g.  sensors) 

□  Send  the  vehicle  data  to  monitoring  center  through  the  Short  Message 
Service  (SMS) 

□  The  real  time  behavior  of  CAN  compares  reasonably  well  to  other  networks. 
In  some  applications  high-priority  messages  are  transmitted  within  a 
millisecond. 

■  Structure  of  CAN 

□  CAN  is  made  up  of  the  different  CAN  nodes  (sensors)  that  connect  to  the 
CAN  Bus. 

□  By  connecting  each  CAN  node  to  the  same  CAN  Bus,  data  can  be 
transmitted  and  received  by  each  node. 

□  The  basic  structure  for  a  CAN  node  will  be  a  micro-processor,  CAN 
controller,  and  CAN  transceiver. 
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11.10.6  Case  Study  -  GM  OnStar 


11.10.6.1  Introduction 

OnStar  is  a  telematics  device  and  a  subscription-based  dashbord  communication 
service  created  by  General  Motors  (GM).  This  telematics  system  combines  vehicle 
control  and  monitoring  systems  with  location  tracking  and  wireless 
telecommunications.  The  service  provided  numerous  safety  and  convenience 
features,  from  emergency  assistance  to  remote  door  unlocking  to  hotel 
reservations.  GM  also  introduced  that  voice-activated  Internet  access  and  cellular 
telephone  services  through  OnStar. 


Figure  11.43:  OnStar  Technology  Map 


1 1. 10.6.2  How  It  Works 

Pushing  one  of  the  three  OnStar  buttons  --  grouped  on  the  instrument  panel, 
rearview  mirror  or  overhead  controls  —  sends  a  signal,  via  satellite,  to  the  main 
OnStar  headquarters  in  Troy,  Mich.  Once  a  signal  is  received,  a  connection  is 
made  by  a  live  OnStar  "Advisor"  via  cellular  technology  and  a  small  speaker/mic  in 
the  vehicle.  The  OnStar  staff  is  trained  to  answer  any  number  of  questions,  from 
the  important  --  EMS  calls.  If  necessary,  they  can  pinpoint  driver  location  using 
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GPS  (global  positioning  system)  satellite  technology  and  give  that  information  to 
the  driver  or  the  ambulance  racing  way. 

If  asked,  they  will  stay  connected  and  give  explicit  directions  to  the  local  hospital  or 
get  back  on  the  main  highway.  If  a  car  stalls,  they  can  run  an  electronic  diagnostic 
on  it  and  tell  the  driver  to  head  to  the  nearest  dealer  or  wait  for  a  tow  truck.  They'll 
even  give  a  call  if  airbag  deploys,  checking  to  make  sure  everyone's  OK  and 
reminding  that  an  emergency  vehicle  is  on  its  way  to  the  driver  at  that  very  moment. 


Figure  11.44:  GM  OnStar 

■  How  GPS  and  OnStar  Works 

GPS  technology  works  by  using  radio  signals  from  24  satellites  orbiting  at  an 
altitude  of  10,900  nautical  miles  above  the  earth.  Each  satellite  calculates  how  long 
it  takes  a  radio  signal  from  the  satellite  to  reach  a  specific  vehicle,  then  calculates 
the  time  to  do  so  using  the  speed  of  light  (186,000  miles/s).  Both  the  satellite  and 
the  vehicle's  GPS  receiver  generate  the  same  pseudorandom  coded  signal. 

OnStar  calculates  the  time  the  signal  travels  by  comparing  how  late  the  satellite's 
code  is  with  respect  to  the  receiver.  That  time  difference  is  then  multiplied  by 
186,000  miles/s,  giving  the  vehicle's  distance  from  one  satellite.  For  the  most 
accurate  measurement  of  vehicle  location,  OnStar  uses  measurement  from  four  of 
the  16  satellites. 

When  communicating  with  an  OnStar  Call  Center,  the  vehicle-identification  number 
(VIN)  and  the  user's  account  number  are  transmitted,  as  are  the  vehicle's  make, 
color,  and  model  year. 
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Figure  11.45:  GPS  and  OnStar 


1 1.10.6.3  A  Closer  Look  Of  OnStar  System 

OnStar  employs  a  three-button  system  (white,  blue,  and  red)  mounted  either  on 
the  rear-view  mirror  or  on  the  dashboard.  Interactive  hands-free  communications 
takes  place  via  a  built-in  cellular  phone  and  the  radio's  speakers.  The  white-dot 
button  is  used  for  voice-activated  cellular  phone  communications  or  connecting 
with  the  Virtual  Advisor.  The  blue  button  connects  the  driver  with  a  Call  Center 
Advisor  for  help  with  a  variety  of  services.  The  red  button  is  used  for  emergencies. 
A  driver's  personal  identification  number  (PIN)  or  a  code  number  is  used  to  initiate 
some  security  services  such  as  door  unlocks  and  stolen-vehicle  location  requests. 
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1  OnStar' s  Virtual  Advisor  service  provides  users  with  a  personalized  Web  home  page  consrshrtg 
of  the*  favorite  preferences 

Figure  11.46:  Personalized  Web  Home  Page  for  OnStar 

Within  the  vehicle,  a  communications  processor  is  located  and  tied  to  a  bus,  the 
car's  radio,  a  remote  GPS  antenna,  and  a  microphone  located  above  the  rear-view 
mirror,  along  with  a  cellular  antenna  that's  mounted  on  the  rear  window,  shown  in 
below  figure.  Though  OnStar  would  not  specify  the  type  of  bus  used,  it  is  believed 
to  be  a  CAN  (controller-area  network)  bus.  All  cars  and  light  trucks  from  1996  to 
the  present  have  been  mandated  by  the  U.S.  Environmental  Protection  Agency 
(EPA)  under  the  OBD  II  (onboard  diagnostics)  Act  to  monitor  the  performance  of 
the  engine's  major  components  and  emission  controls.  Most  OBD  systems  use  the 
CAN  bus  because  it's  best  suited  for  OBD  II.  Analog  cellular-telephone 
communications  are  implemented  instead  of  digital  for  maximum  geographic 
coverage  at  an  affordable  end-user  price.  OnStar  plans  to  offer  digital  and  analog 
service  later. 
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2  Shown  are  key  components  of  tie  OfiStar  nteracfifve  GPS  tracking  system  on  tie 
veh*d«  s*de 

Figure  1 1 .47:  Key  Components  of  the  OnStar  Interface 

The  system  transmits  at  a  mobile  frequency  of  824  to  855  MHz.  The  base 
transmitter  operates  from  824  to  900  MHz.  This  produces  3  W  of  output  power 
using  an  antenna. 

OnStar  use  a  3-W  high-power  phone,  which  is  much  more  than  the  typical  0.6-W 
output  used  in  handheld  cellular  phones.  That  ensures  that  coverage  is  available  in 
just  about  any  geographic  location  a  vehicle  could  conceivably  be  in. 

Once  contacted,  the  Call  Center  has  the  vehicle's  location,  vehicle-identification 
number,  make,  model  year,  and  color  and  is  ready  to  assist.  Airbags  on  the  vehicle 
come  with  sensors.  Once  the  bags  are  activated,  the  sensors  trigger  a  call  to 
automatically  notify  the  Call  Center  of  a  collision,  which  prompts  the  center  to 
contact  the  vehicle,  before  contacting  medical  and  emergency  personnel,  if 
necessary. 

OnStar  will  introduce  an  advanced  automatic  crash  notification  (AACN)  system  on 
approximately  400,000  of  its  most  popular  2004  vehicles,  making  it  the  first 
automaker  to  do  so,  shown  in  the  next  figure.  The  phase-in  of  AACN  into  the  GM 
vehicle  fleet  will  continue  over  several  years.  The  new  system  goes  beyond  the 
ACN  system  already  in  place  on  the  airbags.  By  using  a  collection  of  strategically 
located  sensors,  AACN,  through  the  OnStar  system,  automatically  calls  for  help  if 
the  vehicle  is  involved  in  a  moderate  to  severe  front-,  rear-,  or  side-impact  crash, 
regardless  of  airbag  deployment.  It  provides  crash-severity  information  to  the  Call 
Center  operator,  who  relays  it  to  911  dispatchers,  helping  dispatchers  determine 
the  type  of  emergency  service  required  and  how  fast  it's  necessary. 
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3  In  OnStar's  advanced  automatic  a  ash' notification  (AACN)  systems 
front  and  aide  sensors  along  with  the  sensing  capabilities  of  a  sensing 
diagnostic  module  (SOW)  plus  accelerometer  measure  crash  severity  (a) 

For  moderate  to  severe  crashes  determined  by  the  SDM  crash  data  is 
transmitted  from  the  sensors  to  the  SOM  regardless  of  airbag 
deployment  (b).  VWthwi  seconds,  the  SDM  transmrts  crash  information 
to  the  OnStar  Cal  Center  which  «  then  forwarded  to  91 1  dispatchers 
for  emergency  help  (c). 

Figure  11.48:  OnStar’s  AACN  Systems 

Three  different  subscriber  plans  are  available:  the  basic  Safe  &  Sound  plan  for 
$1 99/year,  Directions  &  Connections  for  $399/year,  and  the  Luxury  &  Leisure  plan 
for  $799/year.  The  basic  plan  offers  emergency  services,  automatic  notification  of 
airbag  deployment,  stolen-vehicle  tracking  (request  made  by  the  driver  from 
outside  the  vehicle  using  a  toll-free  call),  roadside  assistance,  remote  diagnostics, 
door  unlocking,  vehicle  alert  (horns  and  light  activation),  accident/assistance, 
online  concierge  services,  and  hands-free  voice-activated  calling.  The  next-level 
plan  adds  route  support,  information/convenience  services,  and  RideAssist  help. 
The  top  plan  institutes  Personal  Concierge  Services. 
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1 1. 10.6.4  GM  OnStar  Service 


Monitoring 

collision  notification 
vehicle  tracking 
compliance  registration 
vehicle  tracking 
traffic  management 


Information  Services 

information  portals, 
news,  weather,  mobility 
services 


Diagnostics 

diagnostics,  maintenance, 
error  tracking,  software 
service  packs,  etc. 


Communications 

voice  calls 
e-mail 
messaging 


Entertainment 

videos,  navigation,  routing, 
streaming  video,  audio, 
traffic  info 


Figure  11.49:  Telematics  Services  and  Data  Flow 


■  The  Safe  &  Sound  Plan 

Drive  with  confidence  and  peace  of  mind,  knowing  that  when  the  unexpected 
happens,  OnStar's  Safe  &  Sound  Plan  provides  safety  and  security  at  the  touch  of 
a  button  -  24  hours  a  day,  seven  days  a  week. 

o  Online  Concierge  Services  -  Access  self-serve  Online  Concierge  Services 
for  event  tickets,  dining  reservations,  gift  recommendations. 

□  OnStar  MED-NET  -  personal  information  such  as  physician's  name  or 
important  medical  facts  can  be  stored  and  provided  to  a  hospital  emergency 
room  in  the  event  of  a  serious  accident. 

□  Automatic  Notification  of  Air  Bag  Deployment  -  If  a  vehicle's  airbag  deploys, 
an  emergency  signal  is  sent  automatically  to  the  OnStar  Center.  An  Advisor 
will  attempt  to  communicate  with  the  vehicle's  occupants.  If  there  is  no 
response,  or  if  the  car's  occupants  report  an  emergency,  the  Advisor  will 
determine  the  exact  location  of  the  vehicle  using  GPS  and  will  contact  the 
appropriate  nearest  emergency  services  provider.. 

□  Emergency  Services  -  In  an  emergency,  the  driver  simply  touches  the 
emergency  services  button  and  an  OnStar  Advisor  locates  the  vehicle's 
position  on  a  digital  map  and  alerts  the  nearest  emergency  services 
provider. 

□  Roadside  Assistance  -  If  a  customer  has  mechanical  trouble,  a  flat  tire  or 
runs  out  of  gas,  the  OnStar  Center  will  dispatch  the  nearest  GM  service 
provider  to  the  vehicle's  location  without  the  driver  and  passengers  ever 
having  to  leave  the  vehicle. 

□  Stolen-Vehicle  Tracking  -  If  a  subscriber  calls  the  OnStar  Center  to  report  a 
vehicle  stolen,  the  Advisor  can  send  a  signal  to  the  vehicle,  get  its  location 
and  begin  tracking  the  vehicle.  The  Advisor  will  give  the  location  information 
to  the  nearest  police  authority. 
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□  Accident  Assist  -  can  provide  step-by-step  guidance  after  a  minor  traffic 
incident.  OnStar  will  notify  an  insurance  company  of  an  accident,  as  well  as 
provide  a  checklist  of  what  information  is  needed  to  file  a  police  report,  or  to 
speed  an  insurance  claim. 

□  Remote  Door  Unlock  /  Lock  -  OnStar  Advisors  can  unlock  and  lock  your 
doors  in  case  you  locked  your  keys  in  the  car,  or  forgot  to  lock  the  doors 
when  you  left.  The  Advisors  can  also  flash  your  lights  and  honk  the  horn  if 
you  have  trouble  locating  your  vehicle,  or  to  scare  off  unwanted  individuals 
gathered  around  the  vehicle. 

□  Remote  Diagnostics  -  If  a  warning  light  flashes  on  the  vehicle's  instrument 
panel,  the  driver  can  contact  the  OnStar  Center  and  an  Advisor  can  send  a 
signal  to  the  vehicle  asking  for  the  status  of  the  engine  computer.  The 
vehicle  transmits  any  problem  codes  and,  based  on  this  information,  the 
Advisor  recommends  the  required  action,  which  could  include  turning  off  the 
car  and  waiting  for  roadside  assistance,  scheduling  a  service  appointment 
as  quickly  as  possible,  or  getting  the  problem  checked  during  the  next 
scheduled  maintenance  visit 

■  The  Directions  &  Connections  Plan 

Along  with  everything  in  the  Safe  &  Sound  Plan,  OnStar's  Directions  & 
Connections  Plan  helps  you  find  your  way  -  providing  directions,  guidance  and 
assistance  no  matter  where  you  are  or  where  you  need  to  be. 

□  Route  Support  -  When  the  driver  places  a  call  to  the  OnStar  Center  to 
request  assistance,  the  Advisor  pinpoints  the  vehicle's  location  and  provides 
voice-routing  navigation  assistance,  including  help  to  find  an  alternate  route 
if  the  driver  is  caught  in  traffic. 

□  Ride  Assist  -  user  can  call  OnStar  and  request  a  taxi  if  you're  incapable  of 
driving.  If  no  cab  is  available,  we'll  try  to  contact  a  family  member  or  friend 
for  you. 

□  Information/Convenience  Services  -  OnStar  Advisor  can  help  with  a  wide 
array  of  information  and  convenience  services,  including  suggesting 
restaurants  and  making  hotel  reservations. 

■  The  Directions  &  Connections  Plan 

Including  all  the  services  in  the  Directions  &  Connections  Plan,  OnStar's  Luxury  & 
Leisure  Plan  helps  subscribers  make  the  most  of  their  drive  time  with  a  whole 
world  of  helpful  Concierge  Services  -  everything  from  ordering  theatre  tickets  to 
making  restaurant  reservations. 

□  Personal  Concierge  Services  -  OnStar  Concierge  takes  convenience  to  a 
new  level,  offering  subscribers  vacation  planning,  business  assistance  or 
tickets  to  hard-to-get  events.  A  Concierge  Advisor  is  specially  trained  and 
connected  to  an  organization  with  affiliations  with  hotels,  restaurants, 
entertainment  companies  and  other  service  providers  around  the  world. 
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■  Personal  Calling 

OnStar's  Personal  Calling  provides  subscribers  with  nationwide  wireless  service. 
This  voice-activated  system  will  dial  the  number  and  their  party  will  answer  through 
stereo  speakers.  The  one-touch  wireless  connection  and  easy,  hands-free 
communication  provide  them  with  a  superior  blend  of  safety,  security  and 
convenience. 

■  Virtual  Advisor 

Subscriber  can  use  the  OnStar  Virtual  Advisor,  personalized  in-vehicle  connection 
to  the  information  driver  need,  when  need  it.  Using  no  keypads  or  screens,  drivers 
can  access  their  information  by  speaking  simple  voice  commands. 

The  Virtual  Advisor  provides  up-to-date  personalized  information  such  as  Financial 
Services,  Traffic,  Weather,  News,  Sports,  Entertainment,  and  Email  right  in  your 
vehicle.  Users  decide  which  options  they'd  like,  as  well  as  how  and  when  they'd 
like  to  have  these  services  delivered  to  them  in  their  vehicle  MyOnStar.com  makes 
it  easy  for  subscribers  to  set  up  and  change  their  options  at  any  time. 


11.10.6.5  The  Competition 

OnStar  is  not  the  only  technology  in  this  area.  There  are  competing  systems  for 
most  major  automakers.  Mercedes-Benz  uses  the  COMAND  system,  Nissan/lnfiniti 
has  the  Communicator  system,  Jaguar  has  the  ASSIST  system  and  Ford/Lincoln 
has  RESCU.  But  OnStar  seems  to  have  two  things  going  for  it  over  the  others  - 
most  of  the  competition's  services  are  installed  only  in  near-luxury  to  luxury 
vehicles  and  OnStar  appears  to  offer  the  most  bang  for  the  buck. 

The  COMAND  system  is  available  only  in  the  Mercedes  S-Class  models.  Jaguars 
and  Lexuses  have  in-dash  screen  systems,  but  they  often  run  two  grand  or  more 
and  neither  of  those  automakers  are  known  for  brisk  sales  to  the  labor  market. 
Ford  has  a  few  models  offering  RESCU  that  get  close  to  the  middle  class,  but  in  a 
press  release  from  September,  1999,  Ford  says  some  of  the  features  of  the 
"Intelligent  Vehicle  Highway  System  (IVHS)",  like  the  diagnostic  and  active  safety 
and  warning  controls,  and  the  "Vehicle  Emergency-Messaging  System  (VEMS)" 
are  "next-generation  technology  under  development."  VEMS,  however,  is  available 
currently  in  the  Lincoln  LS  and  Lincoln  Continental. 

Although  OnStar  isn't  currently  scheduled  for  base-model  Cavaliers,  it  will  be 
available  in  some  moderately  priced  vehicles  like  the  Blazer  and  the  Impala.  With 
the  number  of  subscribers  estimated  to  grow  2  million  by  2001 . 

As  far  as  features  go,  OnStar  seems  to  be  leading  the  pack.  But,  these  services 
are  not  patentable  or  difficult  to  install  in  alternative  products  --  if  someone  can 
already  give  you  voice  response,  it's  a  simple  step  to  give  you  personalized 
directions.  Most  of  the  competition  has  navigational  abilities,  using  either  an  in¬ 
dash  screen  or  a  cellular  handset,  but  none  seem  to  be  as  easy  to  use  as  OnStar. 
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If  all  goes  well  for  OnStar  and  GM,  this  could  be  a  major  boost  to  the  bottom  line  - 
they  may  have  created  an  effective  and  compelling  reason  to  purchase  a  car  that 
doesn't  involve  styling  or  mechanics. 


1 1. 10.6.6  The  Future  of  OnStar 

OnStar  still  has  a  couple  of  other  ideas  up  its  sleeve.  News  and  stock  quotes,  red 
by  a  voice-automated  system,  will  be  personalized  via  subscribers’  OnStar  Web 
page.  Video  and  audio  streams  also  will  be  personalized  and  downloaded  into 
vehicle  players  and  faxing,  paging  and  voice-mail  access.  Home  activation  of  lights 
and  security  measures  and  grocery  shopping  is  also  on  their  list.  There  are  as 
many  possibilities  as  the  imagination  and  technology  will  allow. 
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11.11.1  Supply  Chain  Reference  Model 

The  attempt  to  improve  the  performance,  flexibility,  visibility  and  readiness  of  a 
logistics  chain  would  comprise  of  the  following  tasks.  The  logistics  chain  has  to  be 
systematically  defined  by  specifying  the  different  entities  that  make  up  the  chain 
and  their  inter-relationships.  Once  it  is  defined  its  performance  can  be  measured 
and  evaluated  using  certain  standard  metrics.  Matching  the  current  performance  of 
the  logistics  chain  with  the  benchmarked  expectations  would  enable  us  to  control  it 
by  altering  the  relationships  between  the  various  entities  within.  Based  on  the 
above  mentioned,  philosophy  the  supply  chain  operations  reference  model 
(SCOR)  was  developed  by  the  supply  chain  council 

What  is  the  SCOR  model?  -  It  is  a  process  reference  model  entailing  the  set  of 
guidelines,  which  help  combine  the  elements  of  business  process  engineering 
benchmarking,  and  leading  practices  into  a  single  framework  Under  SCOR,  supply 
chain  management  is  defined  as  these  integrated  processes:  PLAN,  SOURCE, 
MAKE,  DELIVER  and  RETURN  -  from  the  supplier’s  supplier  to  the  customer’s 
customer,  and  all  aligned  with  the  company's  operational  strategy,  material,  work 
and  information  flows.  The  process  elements  include  the  following 

PLAN:  Assess  supply  resources;  aggregate  and  prioritize  demand  requirements; 
plan  inventory  for  distribution,  production,  and  material  requirements;  and  plan  a 
rough-cut  capacity  for  all  products  and  all  channels. 

SOURCE:  Obtain,  receive,  inspect,  hold,  issue,  and  authorize  payment  for  raw 
materials  and  purchased  finished  goods. 

MAKE:  Request  and  receive  material;  manufacture  and  test  product;  package,  hold 
and/or  release  product. 

DELIVER:  Execute  order  management  processes;  generate  quotations;  configure 
product;  create  and  maintain  customer  database;  maintain  product/price  database; 
manage  accounts  receivable,  credits,  collections,  and  invoicing;  execute 
warehouse  processes  including  pick,  pack,  and  configure;  create  customer  specific 
packaging  /labeling;  consolidate  orders;  ship  products;  manage  transportation 
processes  and  import/export;  and  verify  performance. 

RETURN:  This  process  element  would  include,  defective,  warranty  and  excess 
return  processing,  including  authorization,  scheduling,  inspection  transfer,  warranty 
administration,  receiving  and  verifying  defective  products,  disposition,  and 
replacement.  In  addition  to  these  process  elements  SCOR  includes  enable 
elements  for  each  of  these  processes.  Enable  elements  focus  on  the  information 
policy  and  relationships  to  enable  the  planning  and  execution  of  supply  chain 
activities. 
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Fuiure  2:  The  SCOR  Model 


Figure  11.50:  SCOR  Model 

Scope  of  the  SCOR  model:  SCOR  spans  all  customer,  product,  and  market 
interactions  surrounding  orders  -  purchase  orders,  work  orders,  return 
authorizations,  forecasts,  and  replenishment  orders.  It  also  encompasses  material 
movements  of  raw  material;  work  in  process,  finished  goods,  and  return  goods. 
The  SCOR  model  assumes  training  of  the  personnel,  quality  of  the  products, 
information  technology  and  the  non-SCM  administration.  The  SCOR  model 
includes  three  levels  of  process  detail.  Level  one  defines  the  number  of  supply 
chains  and  how  their  performance  is  measured,  level  two  defines  the  configuration 
of  planning  an  execution  processes  in  material  flow,  using  standard  categories  like 
stock,  to-order,  and  engineer  to-order.  Level  three  defines  the  business  process 
used  to  transact  work  orders,  purchase  orders,  return  authorizations, 
replenishment  orders  and  forecasts. 

SCOR  Project:  Thus  the  SCOR  project  document  would  entail  the  description  of 
existing  management  processes;  the  framework  showing  the  relationships  among 
these  processes;  standard  metrics  that  would  be  used  to  measure  the  process 
performance;  management  practices  that  are  known  to  produce  the  best-in-class 
performance;  and  standard  alignment  of  the  features  and  functionality.  The 
document  may  include  the  success  factors  against  which  the  performance  of  the 
supply  chain  would  be  evaluated.  The  success  factors  specified  within  SCOR  are 
delivery  reliability,  order  flexibility/responsiveness,  supply  chain  cost  effective  asset 
management  and  readiness. 
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The  definition  of  the  supply  chain  using  the  supply  chain  definition  matrix  would 
form  the  first  step  to  a  SCOR  project  implementation.  At  the  SCOR  level  one  the 
focus  is  on  the  entire  supply  chain  as  a  whole  and  the  different  entities  are 
identified  and  the  desired  or  to  be  configuration  noted.  The  metrics  that  would  be 
considered  for  evaluating  performance  would  be  considering  the  end-to-end  supply 
chain.  Once  the  current  performance  is  measured  the  GAP  analysis  would  help 
identify  specific  areas  where  the  process  efficiencies  are  much  lower  than  the 
prefixed  benchmarks. 

The  entities  within  the  supply  chain  can  be  rearranged  so  as  to  improve  the  overall 
efficiency.  The  level  two  processes  help  design  the  material  flow,  the  types  of 
items  and  the  consequent  processes  that  are  used  to  move  the  materials  from  one 
location  to  another  are  identified.  The  metrics  used  would  evaluate  the  material 
flow  performance.  The  key  tools  that  would  be  used  in  defining  the  processes  at 
level  two  are  common  sense  and  facts.  Common  sense  looks  at  the  macro  issues 
of  how  the  material  flows  within  the  supply  chain  and  its  relations  to  strategy  and 
practices,  while  facts  look  at  the  processes  from  a  micro  perspective  of  how  the 
materials  are  moved  from  place  to  place. (functional  and  operational  details).  This 
procedure  is  highly  data  intensive.  The  level  three  involves  work  and  information 
flow  analysis  and  design.  The  ‘as-is’  workflow  is  analyzed  and  the  to-be  workflow  is 
derived  in  order  to  improve  the  efficiency  of  the  supply  chain.  This  would  involve 
specifying  the  information  flows  across  the  different  entities  of  the  supply  chain. 
The  higher  levels  of  the  SCOR  project  would  be  developed  as  the  consequence  of 
the  first  three  levels  of  analysis. 

Though  the  SCOR  model  details  the  processes  and  metrics  that  can  be  adopted  to 
define  the  supply  chain  and  evaluate  its  performance  there  are  some  questions 
which  are  to  be  answered  before  the  actual  SCOR  project  can  be  initiated:  Should 
the  entire  set  of  processes  including  the  supplier’s  supplier  and  the  customer’s 
customer  be  treated  as  a  single  supply  chain?  Do  all  the  supply  chain  threads  have 
and  end-to-end  visibility?  The  quadrant  model  is  a  logical  and  systematic  approach 
that  could  be  used  to  answer  the  above  questions. 

What  is  the  quadrant  model?  It  is  a  logical  technique  for  categorizing  products 
and/or  services,  which  are  transported  through  the  elements  of  the  supply  chain. 
The  schema  shows  two  mutually  perpendicular  axes,  the  horizontal  axis 
corresponds  to  the  value  of  the  product  or  service  towards  mission 
accomplishment  while  the  vertical  axis  qualifies  the  risk/uniqueness/attainability  of 
the  product/service.  Based  one  these  categories  the  products  or  services  can  be 
classified  into  any  of  these  four  quadrants.  The  first  quadrant  which  contains  the 
low  value  low  risk  items  are  categorized  as  routine,  the  low  risk  high  value  items 
are  categorized  as  leveraged,  low  value  high  risk  items  are  categorized  as 
bottleneck  and  the  high  value  high  risk  items  fall  under  the  category  of  critical.  This 
kind  of  a  classification  of  the  different  items  and  products  helps  to  decide  the 
amount  of  visibility  required  for  that  particular  thread  in  the  supply  chain.  It  also 
determines  the  type  of  relationship  that  the  company/organization  should  have  with 
the  suppliers/vendors  of  the  products  in  those  categories. 
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Figure  11.51:  Quadrant  model  showing  various  categories 

Routine:  This  category  comprises  of  those  products  and  services  that  are  of  low 
value  and  easily  attainable  or  substitutable.  In  this  case  the  buyer  would  have 
many  options  from  potential  suppliers.  The  driving  issue  in  procuring  these 
products  could  be  cost  or  ease  of  delivery.  Since  these  are  readily  available  goods 
that  buyer  can  avoid  inventorying  them  to  a  great  extent.  The  procurement  process 
for  these  goods  could  be  need  based.  Since  its  purchased  on  an  as  needed  basis 
an  end-to-end  visibility  at  the  supplier  side  is  not  needed.  The  type  of  relationship 
with  these  suppliers  could  be  at  a  transactional  level  alone. 

Bottleneck:  These  products  have  the  same  value  towards  mission  accomplishment 
as  the  routines,  but  possess  an  element  of  risk  in  that,  the  number  of  suppliers  is 
limited  or  these  items  cannot  be  easily  substituted.  The  most  important  issue  with 
these  items  is  availability  and  so  the  buyer  may  store  these  items  so  as  to  avoid 
the  bottlenecks  developed  within  the  supply  chain.  The  buyer  would  like  to  have 
some  visibility  of  the  inventory  and  the  delivery  facilities  available  with  the  supplier. 
The  relationship  with  these  suppliers  would  ideally  be  a  long-term  relationship. 

Leveraged:  Low  risk/uniqueness  and  high  value  characterize  the  items  within  this 
category,  these  are  sometimes  referred  to  as  commodities.  There  would  be 
multiple  sources  available  to  procure  these  items  and  cost  and  delivery  would  be 
the  key  issues  considered  while  selecting  the  suppliers.  Since  these  items  are 
available  from  multiple  sources,  the  buyer  needs  to  maintain  minimal  inventory. 
The  relationships  with  the  supplier  could  be  long  term  but  the  visibility  of  the  this 
chain  need  to  be  one  step  more  than  the  transactional  level.  For  instance  the 
available  inventory  information  with  the  supplier  could  be  made  available  to  the 
buyer. 

Critical:  These  being  high-value  high-risk  items  need  to  be  managed  carefully  by 
the  buyer.  These  maybe  available  from  very  few  or  almost  one  source  and  are  not 
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replaceable.  These  items  can  be  maintained  in  the  inventory  to  sufficient  levels. 
Moreover  such  critical  items  would  need  to  have  a  full  visibility  of  the  supply  chain 
so  that  decisions  for  procurement  and  the  accurate  delivery  times  can  be 
calculated.  The  relationships  with  such  vendors  would  be  a  long-term  relationship 
and  there  has  to  be  information  sharing  between  the  vendor  and  the  buyer. 

Thus  the  SCOR  model  guides  us  in  defining,  evaluating  and  re-engineering  the 
supply  chain  at  the  strategic  level,  the  operational  level  and  the  level  of  work  and 
information  flow.  In  a  complicated  supply  chain  with  many  nodes  and  numerous 
threads  the  quadrant  model  can  be  used  to  categorize  them  and  thus  amicably 
ensure  visibility  of  the  corresponding  thread. 


1 1 .1 1 .2  Best  Practices  in  Supply  Chain 

In  this  section,  we  give  a  list  of  URLs  which  give  the  best  practices  in  Supply  Chain. 


Grainger  fLCP,  xCM,  xEJ 

http://www.qrainqer.com 

http://www.qrainqer.com/Grainqer/static.isp?paqe=about.html 

http://invest.qrainqer.com/IRUploads/10160/FileUpload/branch  based  business.p 

df 

http://www. qrainqer.com/Grainqer/static. isp?paqe=ci  suppliers.html 

http://www.darwinmaq.com/read/030101/net  transformers  content.html 

http://invest.qrainqer.com/lnvestorRelations/PubCorporateOverview.  aspx?partner= 

MzqOTVRBeE5qQT1QJFkEQUALSTO&product=MzqwU1ZJPVAkWQEQUALSTO 

EQUALSTO 

http://www.qlobalsources.com/PEC/PROFILES/GRAINGER.HTM 
http://www.manufacturing.net/scm/index.asp?lavout=article&articleid=CA1 84359 

http://www.darwinmaq.com/read/03Q1Q1/net  transformers  content.html 

Grainger  established  the  integrated  network  with  more  than  1,200  suppliers  to  fulfill 
customer’s  order.  Moreover,  with  supplier  relationship  management,  data  and 
information  are  transfer  throughout  the  network,  which  can  helps  Grainger  and 
suppliers  manage  their  inventories.  Grainger  also  offer  customers  the  ability  to 
order  facilities  maintenance  products  and  repair  parts  online.  Orders  are  placed 
over  the  Internet  and  transfer  to  one  of  Grainger’s  distribution  centers  for  shipping 
or  to  branches  for  customer  pick-up. 
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FedEx  ( LCP .  xCM,  x0 

http://www.fedex.com 

http://www-fedex.com/us/about/technoloqy/?link=4 

http://users.snip.net/~gbooker/ISYS205/readinqs/3-BuildinQ  e- 

Business  at  FedEx.doc 

http://www.fedex.com/us/supplvchain/industrvsolutions/apparel/ApparelTMS.pdf7li 

nk=4 


http://www.fedex.com/us/supplvchain/industrvsolutions/apparel/ApparelFS.pdf7link 

f4 

http://www.fedex.com/us/supplvchain/industrvsolutions/apparel/Apparelreturn.pdf7l 

ink=4 


http://www.fedex.com/us/customersupport/supplychain/faq/tms.html 

http://www.fedex.com/us/supplvchain/industrvsolutions/industrial/industrialtms.pdf 

FedEx  launched  its  Website,  www.fedex.com,  that  allowed  customers  to  track 
packages  online  and  to  conduct  business  via  the  Internet.  With  the  real-time  data 
transmission  that  assists  in  routing  and  tracking  packages.  Information  recorded  by 
portable  bar-code  scanners  is  transmitted  to  a  central  database  and  can  be  made 
available  to  all  employees  and  customers. 


Delj  fOM.  LCP .  xCM ) 

http://www.dell.com/ 

http://www.dell.com/us/en/qen/casestudies/casestudv  dell  i2.htm 

http://www.deH.com/downloads/qlobal/casestudies/dell  i2  NT  global  deployment. 

pdf 

http://www.dell.com/downloads/us/pedqe/i2%20CS%20lo.pdf 

http://www.intel.com/ebusiness/pdf/affiliates/i2-dell.pdf 

http://www.totalsupplvchain.com/Content/MAGAZINEARTICLE/SCTN/20480/1030 

00. pdf 

http://www.cc.ivu.fi/~hemi/filet/dell.pdf 

http://www.dell.com/us/en/hea/topics/openmanaqe  om  main  main.htm 

http://www.dell.com/html/us/seqments/pub/premier/tutorial/order  status.html 

http://ftp.us.dell.com/app/ps-i2.pdf 
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Dell  applies  the  efficiencies  of  the  Internet  to  its  entire  business.  Customers  can 
order  the  products  by  the  website  http://www.dell.com/  Dell  also  established  the 
real  time  tracking  system,  so  customers  can  see  where  their  goods  are  situated 
during  the  travel  of  the  products  from  the  factory.  Dell  assembly  the  product  based 
on  the  order  from  the  customer.  Since  the  order  has  been  placed,  all  the  materials 
are  shipped  from  Dell’s  suppliers  to  the  assembly  factory.  The  make-to-order 
strategy  reduces  the  inventory  cost  and  also  satisfies  customer  needs. 


Penske  Logistics  (LCP,  xCM,  xPM,  xE} 

http://www.penske.com/ 
http://www.oensketruckleasinq.com/ 
http://3ploqistics.net/Site%20Visits/penske  site  visit.htm 

http://3ploqistics.net/Site%20Visits/Penske  LTEQ.htm 

http://www.underdoqconsultinq.com/what  is  six  siqma.htm 

http://www.isixsiqma.com/ 

http://www.qualcomm.com/press/pr/releases1998/press937.html 

Penske  Logistics  provides  integrated  logistics  services  to  customers  throughout 
the  United  States,  Mexico  and  Canada.  The  wireless  technology  is  used 
throughout  the  logistic  system.  For  example,  Penske  uses  satellite  mobile 
communications  systems  to  provide  customer  the  visibility  to  track  their  products. 
Moreover,  Penske  also  follows  the  Six  Sigma  Methodology 
(http://www.isixsiqma.com/)  to  improve  their  operation  performance. 


Nabisco  (LCP,  OM.  xE.  xCM ) 

http://www.cpfr.org/cpfr  pdf/08  4  1  Nabisco  And  Weqman  Pilot.pdf 

http://www.cpfr.org/ 

http://www.businessweek.com/2000/0Q  47/b370807 1  ,htm 

http://www.microsoft.com/resources/casestudies/CaseStudv.asp7CaseStudyl  D=1 1 

522 


Nabisco  follows  CPFR  strategy  to  share  information  with  their  distributor:  Wegman. 
Nabisco  and  Wegmans  exchange  sales  forecasts  via  the  Web  and  agree  on  an 
amount  to  supply  Wegmans.  Calculations  are  largely  based  on  current  sales  data 
from  the  checkout  counter,  past  patterns,  and  upcoming  promotions.  The  profit  of 
using  CPFR  leads  both  companies  reduce  their  inventory  and  shipping  costs. 
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SCOR  Model  5.0  ( LCP .  xCh/j  OM.  xE} 

http://www.supplv-chain.org/ 

http://www.supplv-chain.org/slides/SCOR5.OOverviewBoQklet.pdf 

http://www.tai.hut.fi/ecomloq/texts/SCOR  notes.pdf 

http://www.sap.  info/index.  php4?ACTION=noframe&url=http://www.sap.info/public/e 

n/print.php4/article/comvArticle-193333c63b63c8acf8/en 

http://www.intel.com/eBusiness/pdf/it/pp023103.pdf 

http://www.findarticles.com/cf  0/ml  121/2  248/536386Q3/p1/article.jhtml?term= 

The  Supply  Chain  Operations  Reference-  model  (SCOR)  is  a  cross-functional 
framework  that  intent  to  integrate  business  process  reengineering  and  process 
measurement.  The  main  objective  of  the  SCOR-model  is  to  provide  a  language  for 
communication  among  supply  chain  partners.  This  is  done  by  establishing 
common  metrics  and  process  descriptions. 


Sapient  fxCM,  xPM} 

http://www.sapient.com/ 

http://www.sapient.com/case/usmc.htm 

Sapient  is  the  consultant  company  that  helps  a  business  enterprise  managing  their 
logistics  and  supply  chains  e.g.  establish  new  enterprise  workflows  or  architectures, 
customer  relationship  management  etc.  Their  customers  are  also  includes  USMC 
logistics. 

Commercial  supply_  chain  software  vendors :  [2  (LCP) 

http://www.i2.com 

http://www.dell.com/us/en/slq/topics/power  ps4qQ1-foreman.htm 

http://www.crmbuver.com/perl/story/201 16.html 

http://www.i2.com/assets/pdf/D8610BF3-D7F1-432D-B9AA6EFBC8727186.pdf 

http://www.i2.com/assets/pdf/3A53AQDQ-BA98-4F80-B0F76E4F0123F6B3.pdf 

http://www.i2.com/assets/pdf/CSS  SEM  SRM  toshiba  css7138  0603.pdf 

http://www.i2.com/assets/pdf/CSS  AER  SPM  sw  airlines  css7141  0603.pdf 
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\2  is  the  supply  chain  management  software  that  helps  the  company  mange  their 
supply  chain.  \2  was  created  based  on  technologies  and  standards  such  as 
Extensible  Markup 

Language  (XML),  Common  Object  Request  Broker  Architecture 

(CORBA  ®),  and  Java  ™.  These  solutions  run  on  industry-leading  application 
servers  to  provide  scalability,  reliability,  and  value  to  \2  ®  users. 

Manugistics  (, LCP ) 

http://www.manuqistics.com 

http.7/www.  redherrinq.com/investor/2Q00/1Q24/inv-manu1 02400.html 

http.V/www.  crmbuver.com/perl/storv/19944.html 

Manugistics  is  the  company  that  provides  software  to  help  customers  solving  their 
problems  in  supply  chain  management,  service  and  parts  management,  pricing 
and  revenue  optimization,  and  supplier  relationship  management.  Moreover, 
Manugistics  also  provides  infrastructure  products,  strategic  consulting,  and 
implementation  services. 

11.11.3  Enterprise  Application  Integration  (EAI)  Practices 


11.11.3.1  Introduction 

Enterprise  Application  Integration  (EAI)  comprises  the  challenge  of  efficiently 
linking  together  diverse  systems  and  applications  across  the  enterprise,  allowing 
the  organization  to  keep  pace  with  and  respond  to  market  changes.  After  creating 
distributed  monolithic,  single-purpose  applications  leveraging  a  hodgepodge  of 
platforms  and  development  approaches  through  generations  of  technology,  users 
and  business  managers  are  realizing  the  importance  of  seamlessly  bridging  them 
together  into  a  single,  unified  enterprise  application  [6].  EAI  addresses  the  above 
problem  by  allowing  many  of  the  stove  pipe  applications  existing  today  to  share 
both  processes  and  data.  With  reference  to  the  USMC  project  [7],  these  stove  pipe 
systems  refer  to  the  various  Operational  Architecture  (OA)  functions  such  as 
request  management,  order  management,  inventory  management,  distribution 
management,  and  so  on.  These  systems  were  typically  custom  built  with  their 
specific  needs  in  mind,  utilizing  the  technology-of-  the-day.  Even  though  the  value 
of  these  applications  remains  fresh,  many  of  the  mission-critical  systems  are 
difficult  to  adapt  to  allow  them  to  share  information  with  other,  more  advanced 
systems. 

The  advantages  of  EAI  are  clearly  evident.  With  the  pressures  of  a  competitive 
business  environment,  moving  IT  management  to  shorter  application  life  cycles, 
financial  prudence  demands  that  increased  utilization  be  made  of  existing 
databases  and  application  services  rather  than  recreate  the  same  business 
processes  and  data  repositories  over  and  over.  Another  upside  of  EAI  is  that 
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customers  are  no  longer  frustrated  as  they  are  not  required  to  deal  with  multiple 
stovepipe  departments  that  had  no  knowledge  of  what  the  other  is  doing.  The  vast 
majority  of  corporations  use  several  generations  of  systems  that  rely  on  a  broad 
range  of  enabling  technologies  such  as  mainframes,  UNIX  servers,  NT  servers  and 
proprietary  platforms  [6].  These  technologies  are  all  providing  some  value  in  the 
enterprise,  but  their  value  is  diminished  if  they  are  unable  to  leverage  other 
enterprise  applications.  Moreover,  the  need  to  integrate  those  systems  with 
packaged  systems  has  been  intensified  with  the  popularity  of  packaged 
applications  such  as  SAP,  PeopleSoft  and  Baan.  Most  software  used  to  solve 
integration  problems  is  classified  as  middleware,  an  umbrella  term  encompassing 
various  communications  and  integration  technologies.  Traditional  middleware 
addresses  the  EAI  problem,  albeit  in  a  limited  manner  [17], 

11.11.3.2  Current  Practices 

There  are  four  distinct  levels  of  EAI  that  have  been  identified  [6,13], 

Level  1  refers  to  point-to-point  integration.  It  involves  establishing  a  basic  data 
interchange  infrastructure  between  applications  though  without  any  real  business 
intelligence  embedded.  Applications  are  transformed  from  closed  to  open  systems, 
wherein  many  application  functions  are  available  through  Application  Program 
Interfaces  (APIs).  Systems  are  loosely  coupled  with  a  degree  of  application 
independence.  Message  Oriented  Middleware  (MOM)  is  a  popular  choice  for  level 
1  integration. 

Level  2.  uses  an  architectural  central  hub  or  bus,  which  controls  information 
exchange  as  opposed  to  point-to-point  application  interfaces.  In  addition,  diverse 
business  rules  governing  data  and  transactions  between  applications  are  now 
aggregated  and  consolidated  at  the  middleware  level.  Message  brokers  and 
application  servers  are  popular  middleware  choices  for  level  2  integration. 

Level  3  integration  involves  a  transition  from  the  sharing  the  information  among 
applications  as  in  level  2,  to  actually  managing  the  information  flow  between 
applications.  Enterprise  Business  model  is  in  place  instead  of  a  mere  Enterprise 
Application  Interface  model.  Process  modeling  tools,  automated  workflow  modeling 
tools  and  decision  support  tools  are  employed  at  this  level. 

Level  4  integration  refers  more  to  the  external  integration  of  the  enterprise  with  its 
partners,  foreign  subsidiaries,  customers  that  facilitates  the  sharing  and  managing 
of  information  assets,  usually  through  a  common  network  infrastructure  such  as 
the  Internet.  Common  data  standards  such  as  XML  are  employed  for  this  purpose. 
Common  applications  at  this  level  are  B2C  (e-business)  and  B2B. 

Middleware  offers  transparency  across  networks,  applications,  and  platforms  by 
enabling  linkages  among  multiple  applications  and  databases  to  support  flow  of 
information  and  processes.  It  includes  basic  connectivity  mechanisms,  such  as 
Remote  Procedure  Calls  (RPCs),  Message  Oriented  Middleware  (MOM), 
Transaction  Processing  Monitors  (TPMs),  and  Object  Request  Brokers  (ORBs),  as 
well  as  complex  application  servers  and  process  management  tools  [17]. 
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Traditional  middleware  offers  program-to-program  connectivity  (Level  1  EAI)  that 
can  be  enabled  using  RPCs  or  MOM  (or  message  queuing)  whereas  ORBs  or 
integration/message  brokers  or  application  servers  (Level  2  EAI)  could  be  used  for 
one-to-many  or  many-to-many  functionality.  The  former  choice  offers  short  term 
simplicity,  however  as  the  number  of  point-to-point  solutions  expand  to 
accommodate  increased  integration  among  multiple  systems,  the  long  term  result 
is  a  complex  tangle  of  software  pipes  entering  and  exiting  applications  that  are 
difficult  to  manage.  ORBs  and  integration  brokers  alleviate  this  drawback  of  point- 
to-point  connectivity  by  offering  a  “middle  ground”  which  are  capable  of  moving 
messages  from  any  type  of  system  to  any  another  type  by  changing  the  format  of 
the  messages.  However  they  are  highly  sophisticated  and  expensive  requiring 
specialized  custom  coding,  that  significantly  alter  both  the  source  and  target 
systems  to  embed  the  middleware  into  the  application  or  data  store.  Compounding 
the  problem  is  the  fact  that  vendors  are  promoting  middleware  suites  and 
integration  software  families,  enforcing  the  use  of  proprietary  software  standards 
that  are  only  interoperable  within  the  suite.  In  essence,  integration  brokers  focus 
on  message  flows  instead  of  technical  integration,  and  they're  too  proprietary.  An 
emerging  class  of  integration  solutions  called  “broker  less  integration”  are 
discussed  in  the  next  section. 

11.11.3.3  Emerging  Trends 


11.11.3.3.1  Data  format  of  choice  -  XML 

With  XML,  data  can  be  exchanged  between  incompatible  systems  [8,10,19],  In  the 
real  world,  computer  systems  and  databases  contain  data  in  incompatible  formats. 
One  of  the  most  time-consuming  challenges  for  developers  has  been  to  exchange 
data  between  such  systems  over  the  Internet.  Converting  the  data  to  XML  format 
can  greatly  reduce  this  complexity  and  create  data  that  can  be  read  by  many 
different  types  of  applications.  A  lot  of  XML  based  B2B  applications  are  under 
development  currently.  Since  XML  data  is  stored  in  plain  text  format,  XML  provides 
a  software-  and  hardware-independent  way  of  sharing  data.  This  makes  it  much 
easier  to  create  data  that  different  applications  can  work  with.  It  also  makes  it 
easier  to  expand  or  upgrade  a  system  to  new  operating  systems,  servers, 
applications,  and  new  browsers.  Other  clients  and  applications  can  access  the 
XML  files  as  data  sources,  like  they  are  accessing  databases.  The  data  can  be 
made  available  to  all  kinds  of  "reading  machines"  (agents)  which  is  the  key  to  a 
successful  application  integration.  In  order  to  make  XML  work  with  many  kinds  of 
databases  and  many  kinds  of  data,  it  had  to  establish  protocols  for  defining  data — 
protocols  that  are  platform-  and  database-independent.  These  protocols,  called 
document  type  definitions  (DTDs)  or  XML  schema,  have  become  an  excellent 
approach  to  interchanging  documents  in  an  environment  where  neither  side  wants 
to  depend  on  the  technology  the  other  side  is  using — a  core  problem  in  EDI  and 
across  e-business. 

For  example,  Microsoft's  EAI  solution  is  based  on  .NET-connected  software  like 
Microsoft  BizTalk  Server  [9,18]  and  Visual  Studio  .NET.  BizTalk  Server  addresses 
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the  integration  problems  by  bringing  together  data  across  different  platforms, 
applications  and  Web  services.  BizTalk  Server  was  built  from  the  ground  up  to 
support  XML  (extensible  Markup  Language)  and  SOAP  (Simple  Object  Access 
Protocol),  both  essential  for  widespread  interoperability  and  modern  B2B 
(business-to-business)  communication. 

Using  XML,  SOAP  and  other  core  Internet  protocols,  BizTalk  Server  unites  EAI, 
B2B  and  business  process  management  functionality  in  a  single  product. 
Companies  can  then  orchestrate  Web  services  and  build  dynamic  business 
processes  that  span  disparate  applications,  platforms  and  business  networks 

The  XML  documents  encapsulating  your  business  logic  should  be  architecture 
neutral  (i.e.,  capable  of  delivery  within  a  SOA  (Service  Oriented  Architectures)  or 
EDA  (Event  Driven  Architectures)  and  over  any  software  stack)  [10].  The  SOA 
approach  consists  of  defining  service  definitions  corresponding  to  the  capabilities 
each  application  wishes  to  allow  other  systems  to  access.  The  event  driven 
architecture  involves  defining  a  dictionary  of  messages  which  applications  can 
either  send  or  receive,  typically  corresponding  to  business  transactions  and 
running  over  messaging  systems  such  as  IBM’s  MQ-series.  To  integrate  a  new 
application,  you  decide  which  of  the  existing  messages  you  will  send  and  receive 
and  create  the  necessary  processing  logic. 

11.11.3.3.2  Broker  less  integration 

An  emerging  class  of  solutions  that  offer  an  alternative  to  traditional  broker-based 
Enterprise  Application  Integration  (EAI)  techniques  and  tools,  is  brokerless 
integration  [11,12].  With  brokerless  integration,  less  programming  is  required, 
allowing  users  to  focus  on  the  business  environment  rather  than  the  complexity  of 
the  application  integration  process  Vendors  like  iWay  have  already  started 
providing  EAI  products  that  accelerate  business  integration  in  a  brokerless  manner. 
By  avoiding  the  excessive  infrastructure,  proprietary  technologies,  and  intrusive 
methods  of  broker  suites,  the  new  broker  less  strategy  provides  the  desired 
flexibility  and  return  on  investment  (ROI)  of  EAI  without  the  usual  investments  of 
money  and  time.  Brokerless  integration  focuses  on  solving  the  most  difficult 
aspects  of  EAI  projects  -  the  technical  connectivity  to  applications  and  data  and 
the  transformations  necessary  to  map  these  systems  to  each  other. 

The  approach  involves  XML,  Web  services,  and  intelligent  adapters,  which  provide 
a  universal  translator  between  applications  that  don't  require  all  of  the 
infrastructure  usually  included  in  integration  broker  suites.  The  broker  less 
integration  approach  allows  any  IT  resource  to  be  accessed  through  XML 
documents.  As  a  result,  tools  such  as  XML  Transformation  Engines  can  simply 
map  from  one  XML  document  to  another  instead  of  writing  custom  transformation 
code  on  non-XML-based  application  programming  interfaces  (APIs).  Even 
nonstandard  systems  such  as  legacy  databases  and  ERP  applications  interact  with 
standardized  XML  documents  that  can  be  incorporated  into  any  application  or 
business  process.  The  broker  less  integration  technology  applies  its  XML 
capabilities  to  conform  to  the  latest  standards  for  SOAP  and  WSDL,  without 
requiring  commitments  to  specific  implementations  in  J2EE  or  .NET.  This  allows 
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users  of  current  or  legacy  technologies  to  immediately  migrate  them  to  Web 
services  without  significant  changes  to  their  architectures,  high-cost  consulting,  or 
retraining.  Intelligent  adapters  provide  immediate  technical  connectivity  to  virtually 
any  information  system,  including  packaged  applications  such  as  SAP  and  Siebel, 
legacy  data  such  as  IMS  and  VSAM,  and  transaction  systems  such  as  CICS  and 
IMS/TM.  The  adapters  also  validate  and  transform  business-to-business 
documents  such  as  EDI  and  XML,  including  specific  industry  formats  such  as 
HIPAA,  HL7,  SWIFT,  and  FIX,  into  XML  documents  [1 1,12]. 


1 1. 11.3.3.3  Directory  service  -  LDAP 

LDAP  (Lightweight  Directory  Access  Protocol)  is  a  derivative  technology,  extracted 
from  the  more  complex  and  heavy-duty  ISO/ITU  X.500  global  directory  system  [8], 
X.500  was  too  big  and  cumbersome  to  use  for  the  Internet  and  the  desktop 
computing  environment.  So  a  “lightweight”  specification  was  developed  that  uses 
fewer  resources  (memory  and  processor  time)  and  is  less  complex  to  implement. 
LDAP  is  a  solution  to  the  problem  posed  by  environments  that  support  more  than 
one  directory  service.  When  LDAP  was  introduced,  most  corporations  were  just 
beginning  to  use  the  directory  services  tied  to  their  operating  system  platforms. 
With  Novell  NetWare  Directory  Service  (NDS),  Sun  (Netscape)  Directory  Service, 
and  now  Microsoft  Active  Directory,  it’s  becoming  more  likely  that  enterprise 
applications  will  be  built  using  directory  services  as  the  repository  of  information 
about  company  resources  such  as  employees,  computers,  data,  and  software. 
Chances  are  also  good  that  most  enterprises  will  have  more  than  one  directory 
service,  which  makes  access  to  multiple  services — most  likely  through  LDAP  — 
increasingly  important  for  EAI. 

11.11.3.3.4  Languages  for  EAI 

As  a  language  of  choice  for  EAI,  there  are  several  excellent  alternatives  such  as 
Java,  C#  and  a  recent  development  called  Python.  Python  is  an  object-oriented 
high  level  interpreted  language  that  is  particularly  suited  to  EAI  [14],  Unlike 
programming  languages  for  web  services  like  Java  and  C#,  Python  is  available  on 
a  wide  range  of  hardware  and  software  platforms  including  Sun,  Intel,  IBM, 
Microsoft  Windows,  Mac  OS,  and  all  Unix  platforms.  Python  provides  option  for 
integration  with  low  level  Application  Program  Interfaces  (APIs)  for  Windows  and 
Unix  platforms,  making  applications  highly  platform  compatible.  In  contrast,  Java 
gives  the  option  for  developing  to  the  lowest  common  denominator  across 
platforms  and  C#  gives  option  to  be  Microsoft-compatible.  Python  programs  can  be 
also  be  extended  using  C,  C++  or  Java,  or  can  be  embedded  in  programs  written 
in  these  languages.  This  portability  and  interoperability  with  a  wide  range  of 
hardware  and  software  make  it  a  good  choice  for  wrapping  legacy  applications.  An 
open  source,  Python  based  framework  and  event  driven  network  called  Twisted, 
provides  powerful,  scalable  and  flexible  EAI  capabilities. 
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1  Executive  Summary 

The  tasks  performed  by  the  PSU-MCRU  team  and  reported  in  the  first  interim  report 
included  the  following: 

>  A  broad  review  of  the  maintenance  systems  in  place  within  the  USMC 

>  Understanding  the  maintenance  activities  as  specified  within  the  operational 
architecture. 

>  Review  of  the  maintenance  levels  and  categories 

>  Review  of  the  maintenance  related  studies  conducted  in  other  DoD  organizations. 

>  Literature  review  of  the  maintenance  practices  within  commercial  organizations. 

The  above  information  was  reviewed  by  the  PSU-MCRU  team  which  helped  in  defining 
a  scenario  and  the  scope  of  the  study.  It  is  felt  that  a  scenario  will  help  in  developing 
detailed  specifications  as  we  further  the  study.  Though  the  scenario  helps  in  identifying 
the  details  of  IDGE  at  a  higher  level,  we  need  use  cases  to  drill  down.  In  terms  of 
technologies,  Condition  Based  Monitoring  (CBM)  and  Data  mining  will  help  immensely 
in  realizing  autonomic  logistics.  In  this  report  we,  therefore  laid  our  emphasis  on  the 
following: 

>  Developing  detailed  use  cases  for  the  maintenance  activities  (Chapter  3). 

>  Developing  data  mining  techniques  that  will  supplement  the  use  of  the  quadrant 
model  so  as  bring  greater  granularity  in  the  classification  of  secondary  repairables 
(SECREPs)  (Chapter  4). 

>  Review  and  analysis  of  condition  based  maintenance  -  with  an  emphasis  on  sensor 
data  acquisition,  processing  and  analysis  (Chapter  5). 

As  a  first  step,  based  upon  our  understanding  of  USMC  operations,  we  have  developed 
a  USMC  scenario  to  build  an  integrated  diagnostics  for  ground  equipment.  Our 
fundamental  approach  (for  this  project)  will  primarily  focus  on  how  a  request  for  a  part  or 
an  item  gets  fulfilled  together  with  its  relevant  maintenance  activities.  A  request  of  any 
kind  will  pass  through  various  Marine  Corps  Organizational  entities  and  experts  for 
execution.  At  this  stage,  the  envisioned  scenario  is  equally  applicable  to  deployment  as 
well  as  to  garrison.  It  must  be  noted  that  this  scenario  needs  to  be  further  enhanced 
based  on  continued  discussion  with  USMC  participants. 

Envisioned  Scenario  for  IDGE: 

We  considered  a  chaotic  and  hostile  combat  environment  (deployed).  Under  this 
environment,  we  assume  three  independent  companies  along  with  a  higher  level 
centralized  Force  Service  Support  Group  (FSSG).  Each  company  consists  of  three 
platoons  and  a  Direct  Support  Combat  Service  Support  Element  Detachment  (CSSE 
Det.).  Each  support  group  has  various  levels  of  sustainment  for  their  unit  (either  platoon 
or  company)  depending  upon  their  mission. 


3 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3) 


We  also  assume  that  entities  like  Manpower,  Tools,  Inventory,  and  Scheduling 
Algorithm  (SA)  are  among  the  other  important  features  that  exist  within  the  support 
groups  (CSSE  Det.  and  FSSG).  Manpower,  Tools  and  Inventory  will  provide  inputs  to 
Scheduling  Algorithms  to  come  up  with  an  optimal  schedule  for  fulfilling  a  request. 

Maintenance  is  an  important  activity  in  the  scenario  considered.  We  assume  that  there 
is  a  mobile  maintenance  unit  for  all  level(s)/unit(s)  to  collect  the  damaged  part(s)  and 
disposition  them  for  rework,  repair  or  disposal.  The  organizational  maintenance  level  is 
placed  at  the  CSSE  Det.  and  intermediate  level  maintenance  at  the  FSSG. 

In  general,  Marine  Corps  maintenance  is  organized  into  three  categories,  namely: 
Organizational,  Intermediate  and  Depot  level.  In  our  scenario  we  consider  the 
organizational  (CSSE  Det.)  and  intermediate  level  (FSSG). 

Organizational  level  maintenance  mission  is  to  maintain  assigned  equipment  mission 
ready  while  continually  improving  the  process.  The  categories  are:  inspections, 
handling,  and  preventive  maintenance.  Intermediate  level  maintenance  mission  is  to 
enhance  and  sustain  combat  readiness  and  mission  capability  of  supported  activities  by 
providing  quality  and  timely  material  support  at  the  nearest  location  with  the  most 
efficient  and  effective  resource  expenditure.  Intermediate  level  functions  include  limited 
repair  commodity-orientated  components  and  end  items,  job  shop,  bay,  and  production 
line  operations  for  special  mission  requirements;  repair  of  printed  circuit  boards, 
software  maintenance,  and  fabrication  or  manufacture  of  repair  parts,  assemblies, 
components,  jigs  and  fixtures. 

By  considering  the  functionalities  of  two  levels  a  part  can  be  directed  to  either  of  the  two 
levels  for  rework  or  servicing.  After  rework  or  servicing  the  part  is  assigned  to  the 
SECREPs  inventory  within  the  maintenance  unit. 

At  the  platoon  level,  requests  are  triggered: 

By  an  operator  (human-in-the-loop) 

-  By  Scheduled/Preventive  Maintenance  (routine  maintenance  done  either  by 
operator  or  technician) 

-  By  Diagnostics/Prognostics  (by  means  of  sensors) 

Experts  at  the  CSSE  Det.  assign  a  priority  value  to  each  of  the  requests  entering  the 
support  service  element.  A  request  will  be  either  for  personnel,  tools  or  parts  from  the 
inventory.  Service  personnel  at  the  CSSE  Det.  level  confirm  with  the  manpower,  tools 
and  inventory  for  request  availability.  Different  events  can  manifest.  They  are: 

1.  Event  1:  Manpower,  Tools  and  Inventory  are  all  available 

2.  Event  2:  Manpower,  and  Tools  are  available 

3.  Event  3:  Tools  and  Inventory  are  available 

4.  Event  4:  Manpower  and  Inventory  are  available 

5.  Event  5:  Only  Manpower  available 

6.  Event  6:  Only  Tools  are  available 


4 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3) 


7.  Event  7:  Only  Parts  (Inventory)  are  available 

Event  1:  Manpower,  Tools  and  Inventory  are  all  available 

Human-in-the-loop/automated  system  inputs  manpower,  tools  and  inventory 
requirement  into  the  Scheduling  Algorithm  for  generating  feasible  assignment.  An 
operator  with  the  required  parts  and  tools  is  then  sent  to  the  specific  location  for 
replacement  and  returns  back  to  the  CSSE  Det.  with  the  damaged  part. 

The  organizational  maintenance  operator  at  the  CSSE  Det.  will  assess  for  percentage 
or  rate  of  damage  on  each  part.  After  assessment,  if  the  rate  damage  falls  above  a 
certain  threshold  value,  the  part  is  sent  to  the  Intermediate  level  maintenance  at  FSSG 
for  rework. 

Event  2:  Manpower  and  Tools  are  (only)  available 

The  service  personnel  send  a  request  to  the  FSSG  for  replenishment.  FSSG  personnel 
will  check  for  SECREP  availability.  If  available,  the  part  is  sent  to  the  concerned  CSSE 
Det.  Otherwise,  FSSG  personnel  make  an  order  for  that  specific  part.  While  placing  an 
order,  they  also  check  with  neighboring  CSSE  Det.’s  for  part  availability  and  visibility. 

If  the  part  is  available  at  another  CSSE  Det.,  the  FSSG  directs  the  owning  CSSE  Det.  to 
send  the  required  part  to  its  neighboring  unit.  FSSG  later  replenishes  both  CSSE  Dets. 
with  the  part. 

Event  2  discussion  is  also  applicable  to  events  3  and  4. 

Figure  1.1  shows  events  1  and  2  in  a  pictorial  form.  We  will  extend  our  work  to  events  5, 
6  and  7  based  upon  the  results  from  events  1,2,3  and  4. 

We  now  have  four  different  events.  Our  next  step  is  how  this  will  capture  the  various 
task  descriptions  assigned  by  our  sponsors: 

Task  2:  Maintenance  Data  Implications 

Task  3:  Logistics  Systems  Information 

Task  4:  Establish  Universal  Data  Support  Requirements 

Task  5:  Identify  Critical  Path  and  Risks  for  One  candidate  system. 

For  the  seven  events  listed,  various  issues  fall  into  place.  They  are: 

1)  How  does  each  platoon  communicate  with  each  other  and  its  FSSG? 

2)  What  kind  of  information  is  communicated? 

3)  What  are  the  various  maintenance  data  acquisition  means? 

4)  How  far  can  this  information  be  sent? 

5)  What  devices  and  means  are  required  to  carry  out  the  above  situation? 

6)  What  support  systems  are  required  to  assist  with  decision  making  at  different 
levels? 
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Figure  1.1 :  Operational  View  for  IDGE  (Events  1  and  2) 


In  order  to  address  the  above  questions,  we  have  studied  the  following: 

Use  cases  representing  the  communication  amongst  various  nodes  (supported 
units,  supporting  units)  (Chapter  3) 

-  Data  mining  techniques  as  an  enhancement  to  quadrant  model  assist  decision 
making  from  a  strategic  point  of  view.  (Chapter  4) 

Maintenance  data  acquisition  using  Vehicle  Health  monitoring  systems,  devices 
and  Information  Technology  (IT)  to  enable  transactions  initiated  by  the  supported 
units. (Chapter  5) 

A  Use  Case  represents  a  unit  of  analysis  that 

1 .  potential  users  can  relate  to  and  confirm, 

2.  designers  can  build  and  deploy, 

3.  implementers  can  test 

4.  project  managers  can  use  to  estimate  effort. 

An  important  ancillary  benefit  of  use  cases  is  that  they  can  be  developed  in  an 
iterative  and  incremental  manner  for  understanding  requirements  -  which  tend  to  be 
fairly  fuzzy  for  any  project  in  the  initial  stages.  We  have  developed  several  use  cases 
related  to  maintenance  activities  in  USMC  at  various  levels.  In  Chapter  2  we  discuss  the 
details  related  to  Use  Cases  and  Use  Case  development. 

The  quadrant  model  gives  us  the  facility  to  partition  SECREPS  into  routine, 
bottleneck,  critical  and  leverage  parts.  However,  in  quad  model,  scientific  principles  for 
such  a  partitioning  are  not  clearly  explored.  A  scientific  methodology  for  partitioning  the 
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SECREPS  space  will  help  in  refined  application  of  business  rules  as  well  as  developing 
appropriate  business  rules.  We  have  developed  and  implemented  several  data  mining 
based  approaches  to  scientifically  partition  the  SECREPS  space.  Chapter  4  contains 
the  details  of  our  development  and  analysis. 

In  order  to  trigger  the  autonomic  logistics  processes  it  is  necessary  to  automate  the 
diagnosis  and  prognosis  processes  for  ground  equipment  health.  Multisensor  data 
fusion  provides  the  opportunity  to  significantly  improve  the  knowledge  of  the  state  of 
USMC  resources  (platforms,  weapon  systems,  etc.).  The  use  of  a  broad  spectrum  of 
sensors  should  improve  system  accuracy,  decrease  uncertainty,  and  make  these 
systems  more  robust  to  changes  in  the  targets  and  environmental  conditions.  Data 
Fusion  systems  seek  to  combine  information  from  multiple  sensors  and  sources  to 
achieve  improved  inferences  than  those  achieved  from  a  single  sensor  or  source. 
Chapter  5  discusses  multisensor  data  fusion  and  fault  diagnosis  in  detail. 
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2  Planned  Work 

1 .  Develop  information  flows  for  the  seven  events  described  in  the  scenario  in  the 
executive  summary. 

2.  Develop  a  conceptual  information  architecture  for  the  scenario 

3.  Understand  MERIT 

4.  Further  improve  the  use  cases 

5.  Continue  the  work  on  multi-sensor  data  fusion/prognosis/diagnosis 

6.  Capture  data  elements 

7.  Work  on  techniques  for  storing  and  cataloging  maintenance  data 

8.  Identify  candidate  systems  and  communication  technologies  for  implementation. 
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3  Use  Cases 


3. 1  Understanding  Use  Cases 

Use  Cases  are  a  technique  that  allows  modeling  what  an  envisioned  system  will  do  (as 
opposed  to  how  these  tasks  will  be  accomplished  with  specific  technologies).  The  initial 
drafts  of  use  cases  are,  therefore,  called  essential  use  cases.  These  use  cases  capture 
the  intended  functionality  of  the  proposed  system  [96]. 

Typically,  use  cases  are  written  using  terminology  that  is  familiar  to  the  potential  users. 
The  use  cases  then  allow  the  system  architects  and  future  designers  the  opportunity  to 
scope  the  project  and  give  it  structure. 

A  single  Use  Case,  thus,  represents  a  unit  of  analysis  that  (a)  potential  users  can  relate 
to  and  confirm,  (2)  designers  can  build  and  deploy,  (3)  implementers  can  test,  and  (4) 
project  managers  can  user  to  estimate  effort. 

An  important  ancillary  benefit  of  use  cases,  therefore,  is  that  they  can  be  developed  in 
an  iterative  and  incremental  manner  for  understanding  requirements  -  which  tend  to  be 
fairly  fuzzy  for  any  project  in  the  initial  stages. 


Definition: 

A  use  case  is  a  scenario  that  yields  a  result  of  measurable  value  to  an  actor. 


An  actor  is  a  role  played  by  a  potential  user.  A  use  case  is,  thus,  documented  as  a 
description  of  interactions  that  an  individual  actor  will  carry  out  with  a  system. 

The  use  case  technique  is  part  of  what  is  known  as  the  Unified  Modeling  Language 
(UML),  which  has  become  the  de  facto  standard  for  specifying  information  systems  [97], 


A  ‘  “•'I” 


Figure  3.1  Primary  Use  Case  Notations 

The  primary  notations  for  use  cases  include  the  Actor  (stick  figure)  and  the  use  case 
(oval)  (see  Figure  3.1  above).  In  addition,  the  functional  groupings  of  use  cases  are 
sometimes  referred  to  as  packages  (see  Figure  3.2  below). 
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Figure  3.2  An  Example  Use  Case  Diagram 

Use  cases,  thus,  provide  a  vehicle  for  communicating  with  the  developers  by  identifying 
scenarios  of  value  to  the  users,  and  provide  a  tool  for  envisioning  and  architecting  that 
can  be  used  to  communicate  with  both,  the  system  developers  and  system  users. 

Keeping  these  objectives  in  mind,  generally,  use  case  steps  are  written  in  an  easy-to- 
understand  structured  narrative  using  the  vocabulary  of  the  domain.  This  is  engaging  for 
users  who  can  easily  follow  and  validate  the  use  cases,  and  the  accessibility 
encourages  users  to  be  actively  involved  in  defining  the  requirements. 


3.2  Using  Use  Cases  to  Envision  IDGE 

For  an  open-ended  problem  such  as  the  proposed  IDGE  initiative,  use  cases  represent 
an  indispensable  tool  precisely  because  of  its  vague,  ill-structured,  futuristic  focus.  The 
myriad  of  actors  involved  in  the  system  need  to  make  their  perspectives  clear.  The 
research  team  needs  a  technique  that  they  can  use  to  understand  and  envision  the 
envisioned  IDGE  effort  in  terms  of  meaningful  chunks.  These  requirements  make  use 
cases  the  appropriate  choice  for  envisioning  IDGE. 

With  the  use  cases,  IDGE  also  inherits  a  rich  stream  of  research  and  a  strategy  that  the 
research  team  can  follow  to  track  progress,  and  integrate  various  elements.  A  simple 
statement  of  this  strategy  is  shown  below. 

1 .  Define  the  problem  informally  in  the  domain  of  interest 

2.  Develop  an  informal  strategy  for  the  domain  of  interest 
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3.  Formalize  the  strategy  as  use  case  chunks 

4.  Use  the  use  cases  to  identify  information  of  interest 

5.  Clarify  specifications 

It  is  the  very  simplicity  of  use  cases  that  makes  them  so  powerful.  The  steps  can  iterate 
a  number  of  times  as  the  outcomes  of  each  inform  the  next  step  as  well  as  the  overall 
process.  The  steps  are  instantiated  for  the  IDGE  below. 

.  First,  the  problem  can  be  defined  informally  to  start  the  process.  In  the  case  of  the 
IDGE  system,  this  can  be  articulated  as  application  of  the  autonomic  logistics 
concept  for  ground  equipment  to  ensure  better  maintenance  of  ground  equipment. 

•  Second,  an  informal  strategy  can  be  developed  for  the  domain  of  interest.  In  case  of 
IDGE,  this  involved  choosing  the  LAV  as  an  exemplar  to  make  the  discussions 
concrete,  and  scoping  the  discussion  by  the  OA  processes  (on  the  top-side)  and  the 
sensor  architectures  (on  the  bottom-side). 

.  Third,  the  strategy  can  be  formalized  as  use  case  chunks.  Identification  of  use  cases 
thus  requires  chunking  the  functionality  of  the  envisioned  system  into  cognitively  and 
pragmatically  manageable  units.  For  the  IDGE,  this  means  understanding  different 
roles  (actors)  and  how  they  will  interact  with  the  proposed  system  at  different  times 
and  to  achieve  different  goals. 

•  Fourth,  the  use  cases  can  be  used  in  a  manner  that  directly  addresses  concerns  of 
interest.  For  the  IDGE,  the  immediate  concerns  of  interest  are  the  data  implications 
and  the  universal  data  requirements.  These  can  be  tagged  to  the  use  case 
descriptions  to  identify  the  data  implications  of  each  use  case. 

.  Finally,  the  specifications  can  be  formalized  to  the  extent  possible  so  the  process 
can  repeat. 

For  the  task  of  understanding  data  implications  of  the  proposed  system,  use  cases, 
therefore,  provide  an  excellent  jump-off  point.  They  allow  the  research  team  to  clarify 
the  requirements  of  users.  These  requirements  can  then  be  translated  into  specific  data 
implications.  Finally,  the  frequencies  of  use  of  these  scenarios  can  be  used  to  compute 
the  data  storage,  transfer  and  communication  implications. 

Over  the  last  few  months,  multiple  iterations  were  done  to  identify  a  first  set  of  use 
cases  for  the  IDGE.  These  are  described  next. 
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3.3  A  Top-Down  View  of  Proposed  Use  Cases  for  IDGE 

Whereas  use  cases  provide  a  window  on  the  scenarios  that  will  be  part  of  the  proposed 
system,  another  perspective  is  also  necessary  to  complement  this  view.  This 
perspective  is  the  architectural  perspective.  Here,  architecture  refers  to  the  arrangement 
of  roles,  hardware  and  necessary  network  connections  that  are  typically  distributed  over 
a  geographical  area. 

For  the  proposed  IDGE  system,  a  preliminary  architecture  can  be  tied  to  the  manner  in 
which  the  organizational  levels  can  be  identified.  These  include  the  following  levels: 

•  The  Vehicle  Level  (in  our  exemplar,  the  LAV) 

•  The  O-Level  (connecting  to  the  Battalion  level  and  the  vehicle  level) 

.  The  1-Level  (connecting  to  the  MEB  and  the  MEF) 

•  The  D-Level  (connecting  to  the  MEF  and  the  Sea-Base 

In  addition,  connections  are  shown  to  the  OA  processes.  Figure  3.3  shows  the 
preliminary  architecture  for  IDGE. 


Figure  3.3  A  Preliminary  Architecture  for  IDGE 
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The  figure  shows  the  Vehicle  level  on  the  left  hand  side,  and  the  three  levels  -  O-level, 
l-level,  and  D-level  in  the  centre.  Towards  the  right,  it  depicts  the  connection  to  the  OA 
processes.  The  cubes  shown  in  the  figure  indicate  either  Processors  or  Devices. 

These  notations  are  part  of  the  Unified  Modeling  Language  (UML)  indicated  earlier.  The 
above  diagram  and  the  diagrams  that  follow  were  created  using  a  Computer  Assisted 
Software  Engineering  (CASE)  tool  called  Rational  Rose™  that  implements  this 
language  (UML)  [98], 

Following  this  preliminary  architecture,  the  use  cases  and  functional  groupings  were 
created.  Figure  3.4  shows  this  overview. 


Requester  in  the  LAV 
(User/  Non  user) 

(from  LAV  level  operations)  operations 
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at  I  level 

(from  Maintenance  level  Operations) 


Maintenance  person  at  D  level 
(from  Maintenance  level  operations) 


Maintenance 
level  operations 


Maintenance  Person  at  O  level 
(from  Maintenance  level  operations) 
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(from  O A  functions) 
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(from  All  level  operations) 


(from  OA  functions)  Manager 

Commande 
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r  of  Platoon 
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Manager 
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Procureme 

oper... 
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(from  All  level  operations) 

LCP 

Manager 
(from  OA  functions) 

Bn  level 
APSSA 

MEB  level 

APSSA 

MEF  level 
APSSA 

Sea  Base  level 
APSSA 

(from  Bnif)vel 
operations) 

(from  MEB  level  ) 
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Figure  3.4  Overview  of  Use  Cases  and  Actors 


The  figure  shows  that  the  overview  contains  several  Packages  i.e.  functional  groupings 
of  use  cases  that  map  to  the  different  levels  indicated  in  the  architecture  (see  Figure  3.3 
earlier). 
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The  figure  also  shows  that  several  actors  that  identified  during  this  process.  Each  of 
these  actors  represents  a  role  that  may  be  played  by  a  person  or  an  information  system. 
For  instance,  the  actor  “Maintenance  Person  at  D  Level”  captures  the  role  that  a  person 
or  group  of  persons  may  fulfill  for  performing  maintenance  at  the  D-level. 

Table  1  below  shows  the  list  of  actors  identified.  Complete  definitions  of  each  Actor  are 
provided  in  Appendix  3.1. 


Table  3.1  List  of  Actors  Identified 


Actor 

Commander  of  Company 

Commander  of  Division 

Commander  of  Platoon 

Commander  of  the  Battalion 

Battalion  level  Active  Passive  Sensor  Signal  Analyst  (APSSA) 

Requestor  in  the  Vehicle  (User/Non-User) 

Subsystem  Sensor 

Maintenance  Person  at  D-Level 

Maintenance  Person  at  1-Level 

Maintenance  Person  at  O-Level 

MEB  Level  Active  Passive  Sensor  Signal  Analyst  (APSSA) 

MEF  Level  Active  Passive  Sensor  Signal  Analyst  (APSSA) 

Distribution  Manager 

Inventory  Manager 

LCP  Manager 

Maintenance  Manager 

Order  Manager 

Procurement  Manager 

Request  Management  Manager 

Warehouse  Manager 

Sea  Base  Level  Active  Passive  Sensor  Signal  Analyst  (APSSA) 

3.4  Documenting  Individual  Use  Cases  in  the  Functional  Groupings 

Following  the  identification  of  functional  groupings  (see  Figure  3.4),  individual  use  cases 
were  identified  in  each  functional  grouping,  and  documented.  This  resulted  in  a  large 
number  of  use  cases,  which  were  then  examined  to  identify  possible  combinations, 
overlaps  or  problems.  This  iterative  process  resulted  in  a  total  of  25  use  cases.  Table 
3.2  below  shows  titles  and  brief  descriptions  of  these  use  cases. 
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Ta 

ble  3.2  List  of  Use  Cases  Iden 

tified 

Level 

Use  Case 

Brief  Description 

1 

All  levels 

Read  component  history  database/ 
View  diagnosis  results 

To  allow  actors  at  various  levels  to  log 
into  component  history  database  to  read 
a  comprehensive  history  report  of  the 
component  viz.  diagnosis  results,  expiry 
dates,  threshold  alarms,  past 

troubleshooting  actions  such  as 

replacement,  repairs  etc.  Also  contains 
further  information  regarding  identity 
codes  etc.  This  is  a  purely  Read-Only 
operation  and  does  not  involve  any 
writing  into  the  database. 

2 

Prognosis  of  LAV 

To  monitor  the  health  of  an  LAV  on  the 
whole  based  on  the  health  of  its 
constituent  subsystems 

3 

Authenticate  received  signals  at 
Battalion 

To  authenticate  the  source  of  sensor 
data  stream/  PDA  form  received  from  the 
LAV  level  to  ensure  that  it  originates 
from  validated  LAVs/  personnel. 

4 

Process  PDA  form  at  Battalion  level 

To  analyze  the  information  received  from 
the  PDA  that  gives  further  description 
about  the  failure  (or  impending  failure)  of 
a  subsystem,  in  order  to  diagnose  the 
problem  successfully. 

5 

Battalion  level 

Escalate  diagnosis  to  MEB  from 
Battalion 

To  upload  sensor  data  stream/  Bn  level 
diagnosis  results  and  also  ship  faulty 
subsystem/  component  from  Bn  to  MEB, 
so  that  MEB  can  assist  in  diagnosis 

6 

Diagnosis  of  subsystem  at  Battalion 

To  diagnose  the  health  of  a  subsystem 
at  Bn,  based  on  information/  inventory 
received  from  LAV  to  determine 
component  that  has  failed/  will  fail 
(source  of  information  could  be  PDA 
form/  sensor  data  stream) 

7 

Trigger  maintenance  action  by  0 
level 

To  trigger  initiation  of  maintenance 
action  by  the  O-level  maintenance  (given 
by  Bn  level) 

8 

Query  a  sensor 

To  ping  /  trigger  the  LAV  system 
processor  to  upload  a  subsystem  sensor 
data  stream,  if  it  did  not  take  place  at  the 
scheduled  instant. 

9 

LAV  level 

Report  out  of  ordinary  event 

To  send  PDA  form  from  LAV  to  Bn  in 
order  to  seek  assistance  from  Bn  level  in 
troubleshooting/  diagnosis  of  faulty 
subsystem  (LAV  mechanic  unable  to 
resolve  problem  by  himself) 

10 

Diagnosis  of  subsystem  at  LAV 

To  diagnose  the  health  of  the  subsystem 
by  LAV  mechanic,  in  order  to  determine 
the  component  that  has  failed/  will  fail, 
once  thresholds  are  breached  by  the 
subsystem  sensor  data  stream 
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Level 


12 


13 


Use  Case _ 

Subsystem  troubleshooting 

assistance/  Escalate  diagnosis  to 
Bn  level 


Prognosis  of  subsystem  at  LAV 


Upload  data  stream  periodically  to 
Bn  level 


Brief  Description _ 

To  decide  the  flow  of  information/ 
inventory  that  will  assist  LAV  mechanic 
in  subsystem  troubleshooting  i.e.  LAV  to 
Bn  (shipping  of  secondary  reparable)  or 
Bn  to  LAV  (Bn  mechanic  assistance  or 
shipping  of  replacements). _ 

To  monitor  the  health  of  an  LAV 
subsystem  by  analyzing  the  data  stream 
from  the  subsystem  sensor  to  detect 
breach  of  thresholds _ 

To  upload  the  sensor  data  stream  at 
periodic  intervals  from  the  LAV  system 
processor  to  the  Bn  level  system 
processor 
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— —  Performing 
Maintenance 


17 


18 


19 


20 


MEB  level 


21 


MEF  level 


Condition  based  maintenance 
action  at  appropriate  level 


Report  Maintenance  action/  Update 
component  history 


Take  corrective  maintenance  action 


Trigger  request  management 


Take  preventive  maintenance  action 


Diagnosis  of  subsystem  at  MEB 


Trigger  Maintenance  action  by  I 
level 


Trigger  maintenance  action  by  D 
level 


For  CBM  the  maintenance  action  is 
performed  when  the  impending  failure 
occurs.  The  processor  unit  from  the  LAV 
detects  the  abnormalities  of  the 
subsystem  or  component.  The  diagnostic 
unit  from  the  corresponding 
organizational  level  queries  information 
from  the  LAV  and  indicates  the  fault. 
Moreover,  it  guides  the  LAV  to  the 
appropriate  maintenance  level. _ 

To  record  the  maintenance  action  taken 
at  appropriate  level  which  will  then 
update  the  component  history  database. 
To  perform  corrective  maintenance  at 
appropriate  level  after  the  component  or 
subsystem  failed. _ 

To  trigger  request  for  components/ 
inventory  to 

external  suppliers  SI  and  Sn  by  either 
maintenance  levels  or  Sea  Base  level. 

To  perform  preventive  maintenance 
action  at  appropriate  level  on 
components/  subsystem  before  they 
actually  fail.  Such  components  need  to 
be  checked  or  repaired  periodically  in 
advance  based  on  expiry  dates  and  so 
on. _ 

To  diagnose  the  health  of  a  subsystem 
at  MEB  based  on  information/  inventory 
received  from  Bn  to  determine 
component  that  has  failed/  will  fail _ 

To  trigger  initiation  of  maintenance 
action  by  the  l-level  maintenance  (given 
by  MEB  level) _ 

To  trigger  initiation  of  maintenance 
action  by  the  D-level  maintenance  (given 
by  MEF  level) 
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Level 

Use  Case 

Brief  Description 

22 

Diagnosis  of  subsystem  at  MEF 

To  diagnose  the  health  of  a  subsystem 
at  MEF  based  on  information/  inventory 
received  from  MEB  to  determine 
component  that  has  failed/  will  fail 

23 

Escalate  diagnosis  to  MEF  from 
MEB 

To  upload  sensor  data  stream/  MEF 
level  diagnosis  results  and  also  ship 
faulty  subsystem/  component  from  MEF 
to  Sea  Base,  so  that  Sea  Base  can 
assist  in  diagnosis 

24 

OA  Processes 

Trigger  request  management 

To  trigger  request  for  components/ 
inventory  to 

external  suppliers  SI  and  Sn  by  either 
maintenance  levels  or  Sea  Base  level. 

25 

Sea-base 

Diagnosis  of  subsystem  at  Sea 
Base 

To  diagnose  the  health  of  a  subsystem 
at  Sea  Base  based  on  information/ 
inventory  received  from  MEF  to 
determine  component  that  has  failed/  will 
fail 

The  use  cases  were  part  of  different  functional  groupings.  The  following  figures  (3.5  to 
3.12)  show  how  these  use  cases  were  part  of  the  different  functional  groupings.  Each 
figure  shows  the  use  cases  identified  at  that  level. 


o  _____ 

Trigger  maintenance  action  by  D 
level 

(from  MEF  level  operation) 

\ 

<<ex>^nd» 

Sea  Base  level 

APSSA 

— ~~<D 

Diagnosis  of  subsystem  at  Sea 

Base 

\  ft- 

<<extepd» 

o> 

Prognosis  of  LAV 

(from  All  level  operations) 

Trigger  Request  Management  (OA 
processes) 

Read  component  history  database/ 

View  diagnosis  results 

(from  All  level  operations) 

Figure  3.5 

Use  Cases  for  Sea-Base  Level  Operations 
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Escalate  diagnosis  from  MEB  to 

MEF 

-9 

<<extend>> 

. 
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\ 

<<extend>> 

o 

Trigger  maintenance  action  by  D 
level 

Read  component  history  database/ 
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d9 
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Figure  3.6  Use  Cases  for  MEF  Level  Operations 
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Figure  3.7  Use  Cases  for  MEB  Level  Operations 
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Figure  3.8  Use  Cases  for  Battalion  Level  Operations 
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Figure  3.9  Use  Cases  for  LAV  Level  Operations 
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Figure  3.10  Use  Cases  for  All  Levels 
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Figure  3.11  Use  Cases  for  OA  Functions 
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Report  Maintenance  action/  Trigger  request  management 

Update  component  history 

Maintenance 
person  at  D  level 

Figure  3.12  Use  Cases  for  Performing  Maintenance  in  Theatre 


3.5  Next  Steps:  Exploiting  Use  Case  Documentation  for  IDGE  Tasks 

The  use  cases  were  documented  by  extending  the  standard  format  suggested  for 
documenting  use  cases  (see,  for  example,  www.rational.com).  The  format  adopted  for 
this  project  reflected  the  nature  of  tasks  that  were  undertaken  by  the  research  team. 

Figure  3.13  below  shows  the  format  adopted  along  with  expected  uses  of  the 
documentation  for  meeting  the  objectives  of  this  project. 


Use  Case:  Name  of  the  use  case 

Precondition:  What  must  have  taken  place  prior  to  executing  this  use  case 

Actors:  The  actor(s)  responsible  for  and  benefiting  from  this  use  case 

Goal:  The  goal  of  the  use  case 

Flow  of  events:  Narrative  as  numbered  set  of  steps 

Alternative  Flows:  Alternative  actions,  if  any,  at  different  steps 

Related  Use-Cases:  Any  use  cases  related  to  this  use  case 

Frequency  of  usage:  Frequency  of  use  case  to  be  obtained  from  users 

Level  of  operation:  Level  in  the  architecture  where  the  use  case  will  be  performed 

Data  Used:  Data  that  will  be  necessary  to  perform  the  use  case 

Data  Generated:  Data  that  will  be  generated  by  the  use  case 

Algorithms  used:  Algorithms  that  may  be  necessary  to  generate  data  for  the  use  case 
Decision  support  tools:  Software  tools  that  may  be  necessary  to  support  execution 

Figure  3.13  Format  Adopted  for  Documenting  Use  Cases 
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Appendix  3.2  shows  a  total  of  20  use  cases  that  were  documented  using  the  above 
format.  The  documentation  shows  some  information  that  will  be  necessary  from  the 
users  for  further  analysis  of  the  documentation  towards  satisfying  the  project  goals. 

Specifically,  the  following  represent  next  steps  that  can  further  exploit  information 
available  in  the  use  case  documentation. 

First,  three  elements  -  Frequency  of  usage  (to  be  obtained  from  users),  Data  Used 
(Data  that  will  be  necessary  to  perform  the  use  case),  and  Data  Generated  (Data  that 
will  be  generated  by  the  use  case)  can  be  used  to  clarify  the  data  implications  for  IDGE. 
For  instance,  consider  a  use  case,  which  is  triggered,  on  average,  once  every  15 
minutes  (i.e.  96  times  a  day)  for  each  of  the  deployed  vehicles  (say,  20  vehicles),  and 
each  time  it  is  invoked,  it  generates  a  data  stream  of  300kb.  This  can  be  used  to 
ascertain  the  total  data  that  needs  to  be  uploaded. 

Second,  the  element  -  Algorithms  used  (Algorithms  necessary  to  generate  data  for  the 
use  case)  can  be  identified  and  mapped  against  the  data  mining  or  CBM  techniques 
available  in  a  bottom-up  fashion.  This  is  where  the  top-down  approach  exemplified  by 
the  use  case  approach  can  connect  with  the  bottom-up  approach  captured  by  the  data 
mining  techniques  reported  elsewhere  as  part  of  this  project. 

Third,  the  element  -  Decision  support  tools  (Software  tools  that  may  be  necessary  to 
support  execution)  can  be  identified  based  on  indications  by  the  potential  users  and 
knowledge  of  the  marketplace.  This  can  be  a  useful  input  to  assessing  viability  of  the 
overall  project  and  for  understanding  lifecycle  costing. 

It  is  expected  that  the  use  cases  themselves  will  be  refined  considerably  during  the 
process  of  accomplishing  the  above  tasks  to  map  against  work  done  in  the  other 
directions  such  as  the  quadrant  model,  the  FMECA  results  and  degrader  results. 

Table  3.3  below  summarizes  these  steps. 
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Table  3.3  Next  Ste 

ps:  Using  the  Use  Cases 

Application 

Description 

Anticipated  Results 

Tasks 

Deriving  Profiles  of 
Usage  Frequencies 
and  Data 

Implications  for  the 
Scenarios  of  Use 

Obtaining  profiles  of 
usage  frequencies  and 
converting  these  to 

understand  data 

transmission  and 

timeliness  rates 

Computations  of 

expected  data  storage 
and  transmission 

across  different  levels 
or  the  architecture 

Task  2.3 

What  data  is  required? 

How  the  data  will  be 
generated/  stored/used? 
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4  Data  Mining  concepts  and  details 


4. 1  Quadrant  Model  Review 

The  quadrant  model  is  a  classification  tool  used  to  categorize  the  elements  along  two 
distinctly  different  attributes.  Relevant  to  this  study,  the  attributes  considered  are  the 
mission  value  and  risk/uniqueness.  The  main  computation  performed  in  this  model  is 
the  quantification  of  risk  and  mission  value  associated  with  the  different  components.  In 
the  generic  quadrant  model,  the  X-axis  represents  the  mission  value  of  a  particular 
component  and  the  Y-axis  represents  the  risk/uniqueness  associated  with  the 
components.  The  value  from  left  to  right  on  the  X-axis  and  bottom  to  up  on  the  Y-axis 
increases  from  low  to  high. 

The  quadrant  model  has  two  'dividers’  that  partition  the  X  -Y  plane  into  four  distinct 
quadrants.  They  are  categorized  as  “Routine,  Leveraged,  Bottleneck  and  Critical”.  Each 
of  the  quadrants  represents  components  with  distinct  levels  of  risk  and  mission  value. 
The  dividers  can  be  adjusted  to  change  the  fraction  of  components  falling  into  the  four 
categories.  Figure  4.1  shows  the  quadrant  model  with  a  sample  of  the  attributes  that 
ascertain  the  belonging  of  the  components  to  the  respective  quadrants. 
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Figure  4.1:  Quadrant  model  showing  the  attributes  &  a  sample  of  the  various 
criteria  that  determine  the  belonging  of  each  component  to  the  respective 
quadrants. 
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With  the  above  concept,  specific  business  rules  can  be  applied  for  each  category  to 
assist  in  decision  making  at  various  levels.  In  addition,  this  will  help  in  identifying  critical 
components  in  the  LAV  for  which  Condition  Based  Maintenance  (CBM)  can  be  enforced 
for  diagnosis  and  prognosis. 

The  quadrant  model  assists  in  decision  making.  Apart  from  the  quadrant  model,  various 
techniques  are  available  for  analysis.  One  such  technique  considered  is”  Data  mining". 
Theoretical  details  of  the  various  Data  mining  techniques  are  detailed  in  the  Appendix 
(7.3).  Combining  data  mining  techniques  with  the  quadrant  model  can  improve  the 
granularity  of  classification  of  SECREPS. 


4.2  Decision  Support  Systems  with  Data  Mining 

In  this  study,  Data  mining  techniques  are  needed  to  support  maintenance  related 
decisions  that  are  made  at  different  levels  (Strategic,  Organization  and  Tactical)  within 
the  USMC.  In  the  quadrant  model  all  the  parts  that  are  classified  as  critical  are  treated 
according  to  the  same  business  rules.  There  is  not  much  scope  for  prioritizing  the 
requirements  of  components  within  each  category  of  the  quadrant  model.  To  achieve 
greater  granularity  the  use  of  other  data  mining  techniques  are  suggested. 

The  primary  decision  considered  here  is  that  of  prioritizing  the  procurement  of 
components  within  a  fixed  budget.  The  input  data  considered  are  similar  to  those  used 
for  the  quadrant  model  analysis  (provided  by  the  sponsors).  Data  elements  used  were 
from  the  FEDLOG,  LDR,  Supply  chain  management  center,  in  combination  with  some  of 
the  simulation  results. 

Though  the  decision  considered  here  is  at  the  strategic  level,  similar  techniques  can  be 
considered  for  the  organizational  and  tactical  levels.  At  the  strategic  level  the  main 
objective  is  to  limit  the  costs  incurred  as  part  of  maintenance  procurement,  while  at  the 
tactical  level  the  emphasis  would  be  on  the  availability  of  the  required  components.  The 
decisions  made  at  the  strategic  level  would  be  based  on  historical  (long  term)  data  while 
the  tactical  level  decisions  would  be  made  in  near  real  time.  It  is  important  that  the 
decision  support  system  developed  is  aligned  along  the  three  different  levels  to  improve 
operational  efficiency.  The  next  sections  give  details  of  the  use  of  specific  data  mining 
techniques  that  can  be  used  to  supplement  the  quadrant  model  analysis.  Figure  4.2 
shows  the  overview  of  the  processing  element  for  data  mining. 
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MAIN  PROCESSOR  FOR  THE  DATAMTMNG 


Figure  4.2:  Processing  elements  for  Data  Mining 


4.3  Implementation  of  Data  Mining  Techniques 

A  brief  example  of  applying  data  mining  techniques  as  a  decision  support  tool  in  the 
IDGE  architecture  is  detailed  below.  Real  implementation  is  conducted  based  on  the 
domain  knowledge  of  Quadrant  model  and  the  given  sample  dataset,  E0947  (LAV-25) 
SECREP.  Classification  (supervised  learning)  algorithms,  linear  regression  indicator 
matrix,  linear  discriminant  analysis,  and  quadrant  discriminant  analysis  are  applied  to 
build  the  predictor  engine  as  shown  in  Figure  4.3.  For  evaluating  and  validating  the 
model,  cross  validation  and  principal  component  analysis  were  conducted. 
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Figure  4.3:  Implementation  of  Data  Mining 


4.3.1  Implementation  of  the  Classification  Algorithm  using  MATLAB 

■  Program  Architecture 

Algorithms  and  techniques  used  in  this  data  mining  study  are  developed  using  the 
MATLAB  6.5.  Following  show  the  role  of  each  module  included  in  the  program  as 
shown  in  Figure  4.4. 

•  LISQ.m  reads  the  original  sample  data  (E0947  SECREPS) 

•  LSIQ.m  calls  CV  NORM.m  to  divide  the  original  data  into  two  sets,  training  and 
test,  according  to  the  cross-validation  method.  The  predictors  (attribute  variables) 
are  also  normalized  in  CV_NORM.m  according  to  the  range  of  those  in  training 
set. 

•  PCA.m  is  called  by  LISQ.m  to  do  the  principal  component  analysis  of  training  set. 
It  transforms  both  the  predictors  in  training  and  test  sets  into  new  predictors. 

•  LISQ.m  selects  the  new  predictors  according  to  the  number  of  variable  reduction. 

•  LRI.m,  LDA.m,  QDA.m  are  called  to  classify  the  given  data  and  provide  the 
performance  measures  for  a  single  experiment. 

•  LISQ.m  takes  the  average  of  K  experiments  from  K-fold  cross-validation. 

•  LISQ.m  summarizes  the  results  (shown  in  Figures  4.6  and  4.7). 
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Figure  4.4:  Program  Architecture 


4.3.2  Validation  and  Evaluation  of  Data  Mining  Techniques 

To  validate  and  evaluate  the  data  mining  techniques,  the  actual  class  and  predicted 
class  for  each  item  (or  NSN)  in  training  dataset  and  test  dataset  were  compared. 


Itemfoi  NSN) 

|  Periscope  | 


Cuuuit  Card 


Attributes  of  Item 


i  i 


Actual  Class 

I  Critical  I 


Inpul 


Predictor 


Output 


Item(oi  NSN) 

Periscope  | 


|  Cm-qal  C-ani  | 


Predicted  Class 
I  Critical  I 


1  R««tmr 


Figure  4.5:  Predict  Class  using  SECREPS  attributes 


4.3.3  Misclassification  Error  rate  of  Classification  Algorithms  with  Principal 
Component  Analysis 

In  addition  to  the  above,  misclassification  error  rates  for  training  dataset  and  test 
dataset  were  analyzed  for  each  applied  classification  algorithms  as  shown  in  Figure  4.6. 

Misclassification  Error  Rate  for  Training  Dataset 

Number  of  mismatched  class  data  {item)  in  training  dataset 
total  number  of  data  {item)  in  training  dataset 

where.  Mismatched  class  data  means  actual  class  for  the  data  {item)  is  different  from 
the  predicted  class 
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Misclassification  Error  Rate  for  Test  Dataset 

Number  of  mismatched  class  data  (item)  in  test  dataset 
total  number  of  data  (item)  in  test  dataset 
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Figure  4.6:  Misclassification  Error  rate  of  Classification  Algorithms  with  Principle 

Component  Analysis 


The  above  figure  shows  that  the  misclassification  error  rates  in  training  and  test  dataset 
decrease  as  the  number  of  principle  components  increases.  This  is  an  obvious  trend. 
By  adding  predictors  (more  principle  components),  i.e.  by  increasing  the  complexity  of 
the  boundary,  it  is  always  easier  to  classify  each  set  in  samples  when  their 
classifications  are  known. 
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4.3.4  Sensitivity  and  Specificity  Analysis  of  Classification  Algorithms  with 
Principle  Component  Analysis 

As  another  effective  method  to  validate  and  evaluate  the  model,  sensitivity  and 
specificity  analysis  is  conducted  with  dimension  reduction  analysis,  principle  component 
analysis. 

Sensitivity.  Probability  of  predicting  a  specified  class  (ex.  Bottleneck)  given  that  the  true 
state  is  specified  as  the  class  itself. 

TYPE  I  ERROR  (%)  =  100  -  Sensitivity 

Specificity.  Probability  of  predicting  other  classes  (ex.  Critical,  Leverage,  and  Routine) 
given  that  the  true  state  is  the  other  classes  themselves. 

TYPE  II  ERROR  (%)  =  100  -  Specificity 
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Figure  4.7:  Sensitivity  and  Specificity  Analysis  of  Classification  Algorithms  with 

Principle  Component  Analysis 


The  above  figures  give  a  close  look  to  the  misclassification  errors  for  test  set.  The  error 
can  be  categorized  into  two  types,  and  the  misclassification  errors  are  thus  the  weighted 
average  of  Type  I  and  Type  II  errors. 

These  figures  show  that  Type  I  and  Type  II  errors  can  be  reduced  through  variable 
(dimension)  reduction,  for  Linear  Regression  Indicator  matrix  (LRI),  Linear  Discriminant 
Analysis  (LDA),  and  Quadratic  Discriminant  Analysis  (QDA). 
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5  Sensor  Fusion  and  Fault  Diagnosis 

Multisensor  data  fusion  provides  the  opportunity  to  significantly  improve  the  knowledge 
of  the  state  of  USMC  resources  (platforms,  weapon  systems,  etc.).  The  use  of  a  broad 
spectrum  of  sensors  should  improve  system  accuracy,  decrease  uncertainty,  and  make 
these  systems  more  robust  to  changes  in  the  targets  and  environmental  conditions.  A 
key  challenge  becomes  how  to  fuse  these  data  to  achieve  inferences  that  cannot  be 
achieved  using  a  single  sensor  or  source.  Data  Fusion  systems  seek  to  combine 
information  from  multiple  sensors  and  sources  to  achieve  improved  inferences  than 
those  achieved  from  a  single  sensor  or  source.  This  section  of  the  report  describes 
the  concept  of  multisensor  data  fusion,  assessment  of  the  state  of  technology  and 
application  of  data  fusion  to  condition  based  monitoring  of  systems  and  platforms. 
Examples  of  these  applications  to  rotorcraft  and  land  vehicles  are  also  provided.  A  brief 
summary  is  also  provided  of  application  of  information  fusion  for:  (1)  monitoring  the 
condition  of  individual  light  armored  vehicles  (LAV)  and  (2)  monitoring  the  location  and 
health  of  several  LAVs  in  a  networked,  enterprise  setting. 

The  methods  and  techniques  described  in  the  fault  diagnosis  examples  are  not  limited 
to  air  vehicles.  They  can  be  used  to  a  variety  of  mechanical  equipment  in  military  and 
industrial  settings.  In  fact,  systems  employing  such  techniques  are  presently  being 
tested  at  by  the  US  Navy  and  US  Army  for  their  rotorcraft  applications.  Also,  several 
industrial  systems  for  fault  diagnosis  are  becoming  available.  The  importance  of 
presenting  the  appropriate  information  to  the  user  is  now  being  recognized  in  the 
implementation  of  diagnostic/prognostic  systems. 

When  conducting  the  top  degrader  study  for  the  LAV,  data  from  all  of  the  LAV  variants 
was  included.  This  is  one  of  the  reasons  why  the  degrader  study  focused  on  the  drive 
train  of  the  vehicles  because  it  is  a  common  system  across  all  of  the  variants.  The 
process  used  in  the  top  degrader  study  utilized  the  MIMMS  data,  included  only  data  for 
the  LAV.  As  there  are  not  many  common  shared  components  between  the  LAV  and 
other  Marine  Corps  ground  platforms  (except  for  the  U.S.  Army  Stryker  Vehicle),  the 
specific  MIMMS  data  used  may  not  be  very  transferable  to  other  ground  vehicle. 
However,  if  MIMMS  data  from  a  specific  ground  platform  were  available,  the  same 
systematic  analysis  used  for  the  degrader  study  could  be  conducted  on  that  data  set  as 
well.  Moreover,  the  FMECA  process  itself  is  applicable  to  any  system  under 
consideration. 

A  goal  of  this  study  is  to  establish  templates  that  can  apply  to  any  piece  of  ground 
equipment  with  a  standard  means  to  deploy  diagnostics/prognostics,  track,  evaluate, 
anticipate  failure,  activate  the  supply/maintenance  system  to  request,  order  and  repair 
the  item  based  upon  varying  time  constraint  scenarios.  Indeed,  data  fusion  assists  in 
this  objective  greatly  due  to  its  ability  to  abstract  the  data  into  information  to  be  utilized 
at  higher  levels  of  the  system  hierarchy.  Data  fusion  is  applicable  at  all  levels  of  the 
system  hierarchy.  At  the  lower  levels  its  goal  is  to  bring  together  diverse  data  sources 
and  extract  key  information  that  is  indicative  of  the  equipment  condition.  At  the 
intermediate  levels,  its  goal  is  to  integrate  diverse  information  sources  to  evaluate  the 
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system  behavior  and  assess  its  ability  to  handle  its  mission.  In  addition,  at  this  level 
actions  for  maintenance  and  mission  re-planning  could  be  generated.  At  the  higher 
levels,  the  goal  is  to  provide  contextual,  actionable  information  to  various  users  in  the 
networked  enterprise.  The  examples  of  systems  provided  in  this  review  present  some 
demonstrations  at  various  levels.  However,  not  all  the  previous  work  has  been  applied 
to  ground  vehicles.  Yet,  most  of  the  methodology  and  many  techniques  can  be  rapidly 
applied  to  ground  vehicles  applications. 

Summary  of  Accomplishments 

During  the  initial  study,  the  following  have  been  accomplished: 

•  Reviewed  existing  health  and  usage  monitoring  systems  (HUMS)  for  military  and 
commercial  applications; 

•  Conducted  a  survey  of  data  fusion  technology 

•  Surveyed  commercial  off  the  shelf  (COTS)  software  for  data  fusion  applications 

•  Developed  a  concept  and  architecture  for  condition  monitoring  of  systems 

•  Reviewed  benefits  of  data  fusion  for  improved  situation  assessment  in  vehicle 
monitoring  applications 

•  Performed  an  initial  assessment  of  the  applicability  of  data  fusion  for  USMC 
monitoring  of  platforms  and  weapons  systems. 

•  Assessed  the  application  of  data  fusion  to  LAV  health  and  situation  monitoring 

•  Assessed  the  application  of  data  fusion  for  monitoring  multiple  LAVs  in  a 
networked,  enterprise  setting. 

Next  Steps 

Near  term  activities  for  the  second  part  of  this  task  include  the  following: 

•  Develop  a  system  level  concept  for  intelligent  preparation  of  the  logistics  battle- 
space  using  data  fusion  concepts 

•  Review  data  elements  and  OA  architecture  implications  for  data  fusion 

•  Refine  the  data  fusion  concepts  for  USMC  applications  at  the  vehicle  level 

•  Apply  FMECA  and  Use  Cases  methods  into  data  fusion  implementation  for  the 
vehicle 

•  Demonstrate  prototype  algorithms  for  data  fusion  at  the  signal  and  report  level. 

5. 1  Concept  and  Model  of  Data  Fusion 

The  extensive  legacy  of  department  of  defense  applications  such  as  automated  target 
recognition,  situation  assessment  and  threat  assessment  provides  an  opportunity  for 
development  of  sophisticated  monitoring  systems.  In  this  section  the  taxonomy  and 
model  for  data  fusion  is  presented. 
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New  sensing  technology  provides  the  opportunity  for  distributed  sensing  of  the 
environment  using  satellites,  aircraft,  underwater  vehicles,  mobile  robotic  devices,  and 
other  platforms.  Sensed  data  may  include  seismic,  acoustic,  radio  frequency,  infrared, 
visible,  and  environmental  sensors  to  measure  a  wide  cross-section  of  the  environment. 
Special  sensors  may  be  developed  to  monitor  particular  chemical  or  biological  effects. 
Moreover,  rapid  advances  in  microprocessors,  advanced  signal  and  image-processing 
algorithms,  and  improved  communications  provides  the  capability  for  smart  distributed 
sensing.  Data  Fusion  systems  seek  to  combine  information  from  multiple  sensors  and 
sources  to  achieve  improved  inferences  than  those  achieved  from  a  single  sensor  or 
source.  Applications  of  data  fusion  related  to  the  Department  of  Defense  (DoD)  span 
a  number  of  areas  including  automatic  target  recognition  (AIR),  identification-friend-foe- 
neutral  (IFFN),  smart  weapons,  battlefield  surveillance  systems,  threat  warning  systems 
(TWS),  and  systems  to  support  precision  guided  weapons.  Waltz  and  Uinas  [91],  Hall 
[51],  and  Hall  and  Llinas  [44]  provide  a  general  introduction  to  multisensor  data  fusion. 
Additional  information  can  be  obtained  from  the  texts  by  Blackman  [11],  Antony  [2],  and 
Hall  [49].  Data  fusion  systems  typically  use  a  variety  of  algorithms  and  techniques  to 
transform  the  sensor  data  (e.g.,  radar  returns,  and  infrared  spectra)  to  detect,  locate, 
characterize,  and  identify  entities  such  as  aircraft  and  ground-based  vehicles.  These 
techniques  include  signal  and  image  processing,  statistical  estimation,  pattern 
recognition,  and  many  others  (see  Hall  and  Linn  [41]).  In  addition,  the  fusion  systems 
may  use  automated  reasoning  techniques  to  understand  the  context  in  which  the 
entities  are  observed  (i.e.,  situation  assessment)  and  to  understand  the  intent  and 
possible  threat  posed  by  the  observed  entities  (i.e.,  threat  assessment). 

Over  the  past  two  decades,  an  enormous  amount  of  DoD  funding  has  been  applied  to 
the  problem  of  data  fusion  systems,  and  a  large  number  of  prototype  systems  have 
been  implemented  (Hall,  Linn,  and  Llinas  [50]).  The  data  fusion  community  has 
developed  a  data  fusion  process  model  [62],  a  data  fusion  lexicon  [94],  and  engineering 
guidelines  for  system  development  [83].  While  a  significant  amount  of  progress  has 
been  made  (Hall  and  Llinas  [43],  [44]),  much  work  remains  to  be  done.  Hall  and  Garga 
[38],  for  example,  identified  a  number  of  pitfalls  or  problem  areas  in  implementing  data 
fusion  systems.  Hall  and  Llinas  [45]Error!  Reference  source  not  found,  described 
some  shortcomings  in  the  use  of  data  fusion  systems  to  support  individual  soldiers,  and 
M.  J.  Hall,  S.  A.  Hall  and  Tate  [53]  discuss  issues  related  to  the  effectiveness  of  human- 
computer  interfaces  for  data  fusion  systems.  Next,  the  Data  Fusion  process  model 
developed  by  the  Joint  Directors  of  Laboratories  Data  Fusion  Working  Group  will  be 
reviewed. 


5.2  JDL  Model  for  Data  Fusion 

A  brief  summary  of  the  Joint  Directors  of  Laboratories  (JDL)  data  fusion  process  model 
is  provided  next  [62],  [51],  [44],  A  top-level  view  of  the  model  is  illustrated  in  Figure  5.1, 
and  a  summary  of  the  processes  is  shown  in  Table  5.1.  This  model  is  commonly  used 
in  the  data  fusion  community  to  assist  communications  concerning  data  fusion 
algorithms,  systems,  and  research  issues.  It  will  be  used  here  for  the  same  purpose. 
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Figure  5.1:  The  JDL  Data  Fusion  Process  Model. 


The  JDL  Data  Fusion  Working  Group  was  established  in  1986  to  assist  in  coordinating 
DoD  activities  in  data  fusion,  and  to  improve  communications  among  different  DoD 
research  and  development  groups.  Led  by  Frank  White  (NOSC),  the  JDL  working 
group  performed  a  number  of  activities  including;  (1)  development  of  a  data  fusion 
process  model9,  (2)  creation  of  a  lexicon  for  data  fusion  [94],  (3)  development  of 
engineering  guidelines  for  building  data  fusion  systems  [83],  and  (4)  organization  and 
sponsorship  of  the  Tri-service  Data  Fusion  Conference  from  1987  to  1992.  The  JDL 
Data  Fusion  Working  Group  has  continued  to  support  community  efforts  in  data  fusion, 
leading  to  the  annual  National  Symposium  on  Sensor  Data  Fusion  and  the  initiation  of  a 
Fusion  Information  Analysis  Center  (FUSIAC16). 


Table  5.1:  Summary  of  JDL  Processes  and  Functions 

Process  components 

Process  Description 

Functions 

Sources  of  information 

Local  and  remote  sensors  accessible  to 
the  data  fusion  system;  information  from 
reference  systems  and  human  inputs 

Local  and  distributed 
sensors;  external  data 
sources;  human  inputs 

Human  Computer 

Interface  (HCI) 

Provides  an  interface  to  allow  a  human  to 
interact  with  the  fusion  system 

Graphical  displays; 

natural  language 

processing 

Source  Preprocessing 

Processing  of  individual  sensor  data  to 
extract  information,  improve  signal  to 
noise,  and  prepare  the  data  for 
subsequent  fusion  processing. 

Signal  and  image 

processing;  canonical 

transformations;  feature 
extraction  and  data 

modeling 

Level  1  Processing: 
Object  Refinement 

Association,  correlation,  and  combination 
of  information  to  detect,  characterize, 
locate,  track,  and  identify  objects  (e.g., 
tanks,  aircraft,  and  emitters). 

Data  alignment; 

correlation;  position, 

kinematics,  attribute 

estimation;  object  identity 
estimation; 

Level  2  Processing: 

Development  of  a  description  of  the 

Object  aggregation: 
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Situation  Refinement 

current  relationships  among  objects  and 
events  in  the  context  of  their  environment. 

event  and  activity 

interpretation;  context- 

based  reasoning 

Level  3  Processing: 
Threat  Refinement 

Projection  of  the  current  situation  into  the 
future  to  draw  inferences  about  enemy 
threats,  friendly  and  enemy  vulnerabilities, 
and  opportunities  for  operations. 

Aggregate  force 

estimation;  intent 

prediction;  multi¬ 
perspective  analysis; 

temporal  projections 

Level  4  Processing: 
Process  Refinement 

A  meta-process  that  seeks  to  optimize  the 
on-going  data  fusion  process  (e.g.,  to 
improve  accuracy  of  inferences,  utilization 
of  communication  and  computer 

resources) 

Performance  evaluation; 
process  control;  source 
requirement 

determination;  mission 
management 

Data  Management 

Provide  access  to,  and  management  of, 
dynamic  data  fusion  data  including;  sensor 
data,  target  state  vectors,  environmental 
information,  doctrine,  physical  models,  etc. 

Data  storage  and 

retrieval;  data  mining; 
archiving;  compression; 
relational  queries  and 
updates 

The  JDL  model  is  a  two  layer  hierarchical  model  that  identifies  fusion  processes, 
processing  functions  and  processing  techniques  to  accomplish  the  functions.  The 
model  was  intended  for  communications  among  data  fusion  researchers  and 
implementation  engineers,  rather  than  a  prescription  for  implementing  a  fusion  system 
or  an  exhaustive  enumeration  of  fusion  functions  and  techniques.  A  technology 
assessment  of  data  fusion  and  details  of  some  updates  to  the  JDL  data  fusion  model 
are  given  in  the  Appendix  7.4  on  Sensor  Fusion  and  Fault  Diagnosis. 

5.3  Pitfalls  in  Data  Fusion 

The  previous  part  of  this  chapter  and  its  accompanying  appendix  has  provided  a  broad 
overview  of  the  state  of  data  fusion  technology  and  identification  of  potential  research 
issues.  A  practitioner  might  well  ask  the  question;  so  what  do  I  do  tomorrow  to 
implement  a  system?  What  are  some  problems  and  challenges  need  to  be  addressed? 
It  is  well  beyond  the  scope  of  this  chapter  to  provide  a  detailed  prescription  for  the 
implementation  of  data  fusion  systems.  However,  there  are  several  areas  worth  noting. 
First,  Bowman  and  Steinberg  [83]  provide  an  overview  of  the  general  systems 
engineering  approach  for  implementation  of  data  fusion  systems.  Engineering 
guidelines  for  selection  of  correlation  algorithms  are  described  by  Llinas  et  al  [69], 
Several  texts,  such  as  those  of  Hall  [51]  and  Waltz  and  Llinas  [91]  provide  detailed 
information  on  data  fusion  algorithms.  R.  Antony  [2]  describes  issues  in  data  base 
management  systems,  and  texts  are  available  on  specific  applications  to  target  tracking 
(e.g.,  Blackman  [11])  and  signal  processing  techniques  [88]. 

Hall  and  Garga  [38]  have  discussed  the  problem  of  implementing  data  fusion  systems 
and  identified  a  number  of  problems  or  pitfalls.  These  include  the  following  dictums. 
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•  There  is  no  substitute  for  a  good  sensor  -  no  amount  of  data  fusion  can 
substitute  for  a  single  accurate  sensor  that  measures  the  phenomena  that  you 
want  to  observe. 

•  Downstream  processing  cannot  make  up  for  errors  (or  failures)  in  upstream 
processing  -  data  fusion  processing  cannot  correct  for  errors  in  processing  (or 
lack  of  pre-processing)  of  individual  sensor  data. 

•  Sensor  fusion  can  result  in  poor  performance  if  incorrect  information  about 
sensor  performance  is  used  -  A  common  failure  in  data  fusion  is  to  characterize 
the  sensor  performance  in  an  ad  hoc  or  convenient  way.  Failure  to  accurately 
model  sensor  performance  will  result  in  corruption  of  the  fused  results. 

•  There  is  no  such  thing  as  a  magic  or  golden  data  fusion  algorithm  -  Despite 
claims  to  the  contrary;  there  is  no  perfect  algorithm  that  is  optimal  under  all 
conditions.  Often  real  applications  do  not  meet  the  underlying  assumptions 
required  by  data  fusion  algorithms  (e.g.,  available  prior  probabilities  or 
statistically  independent  sources). 

•  There  will  never  be  enough  training  data  -  In  general  there  will  never  be  sufficient 
training  data  for  pattern  recognition  algorithms  used  for  automatic  target 
recognition  or  IFFN.  Hence,  hybrid  methods  must  be  used  (e.g.,  model-based 
methods,  syntax  representations,  or  combinations  of  methods). 

•  It  is  difficult  to  quantify  the  value  of  a  data  fusion  system  -  A  challenge  in  data 
fusion  systems  is  to  quantify  the  utility  of  the  system  at  a  mission  level.  While 
measure  of  performance  can  be  obtained  for  sensors  or  processing  algorithms, 
measures  of  mission  effectiveness  are  difficult  to  define  [91]. 

•  Fusion  is  not  a  static  process  -  The  data  fusion  process  is  not  static,  but  rather 
an  iterative  dynamic  process  that  seeks  to  continually  refine  the  estimates  about 
an  observed  situation  or  threat  environment. 

We  note  that  these  issues  must  be  addressed  for  implementation  of  an  effective  data 
fusion  system.  Next,  we  discuss  how  data  fusion  is  valuable  in  fault  diagnosis. 


5.4  Application  of  Data  Fusion  to  Diagnosis 

The  problem  of  determining  the  condition  of  complex  mechanical  systems  and 
accurately  predicting  remaining  useful  life  is  a  challenging,  multidisciplinary  problem. 
Scientific  issues  in  Condition-based  maintenance  (CBM)  range  from  understanding 
fundamental  failure  phenomena  in  materials  to  advanced  sensing,  fusion  of  multisensor 
data,  automatic  pattern  recognition,  mathematics  of  complex  system  evolution, 
distributed  computing  and  sensing  systems,  and  automated  reasoning.  The  integration 
of  these  disciplines  to  address  the  CBM  problem  advances  basic  knowledge  in  each  of 
the  component  scientific  disciplines. 

The  key  to  effectively  implementing  CBM  is  the  ability  to  detect,  classify,  and  predict  the 
evolution  of  a  failure  mechanism  with  sufficient  robustness — and  at  a  low  enough  cost — 
to  use  that  information  as  a  basis  to  plan  maintenance  for  mission-  or  safety-critical 
systems.  “Mission  critical”  refers  to  those  activities  that,  if  interrupted,  would  prohibit  the 
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organization  from  meeting  its  primary  objectives.  “Safety  critical”  functions  must  remain 
operational  to  ensure  the  safety  of  humans  (e.g.,  airline  passengers).  Thus  a  CBM 
system  must  be  capable  of: 

•  Detecting  the  start  of  a  failure  evolution 

•  Classifying  the  failure  evolution 

•  Predicting  remaining  useful  life  with  a  high  degree  of  certainty 

•  Recommending  a  remedial  action  to  the  operator 

•  Taking  the  indicated  action  through  the  control  system 

•  Aiding  the  technician  in  making  the  repair 

•  Providing  feedback  for  the  design  process 

These  activities  represent  a  closed-loop  process  with  several  levels  of  feedback,  which 
differentiates  CBM  from  preventive  or  time-directed  maintenance.  In  a  preventive 
maintenance  system,  time  between  overhaul  (TBO)  is  set  at  design,  based  on  failure 
mode  effects,  criticality  analyses  (FMECA),  and  experience  with  like  machines’  mortality 
statistics.  The  general  concept  of  a  CBM  system  is  shown  in  Figure  5.3. 


Models 


Sensing 


^Classi  fica  tion^/* 


History 


Figure  5.3:  Concept  of  a  Health  Monitoring  System  Error!  Reference  source  not 
found.. 


The  intelligent  monitoring  system  shown  in  Figure  5.3  has  multiple  components  and 
functions  including;  (1)  active  and  passive  sensors,  (2)  signal  processing  and  feature 
extraction,  (3)  pattern  classification,  (4)  multi-sensor  data  fusion,  (5)  automated 
reasoning,  (6)  models,  (7)  historical  data  input,  (8)  mission  constraints,  and  (9)  human- 
in-the-loop  decision  making.  More  details  about  condition-based  maintenance 
approach  and  implementation  issues  pertaining  to  it  are  given  in  Appendix  (7.4)  on 
Sensor  Fusion  and  Fault  Diagnosis. 
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5.5  Fault  Diagnosis  Examples 

Multisensor  data  fusion  has  been  recognized  as  an  enabling  technology  for  both  military 
and  non-military  applications.  However,  improved  diagnosis  and  increased  performance 
do  not  result  automatically  from  increased  data  collection.  The  data  must  be 
contextually  filtered  to  extract  information  that  is  relevant  to  the  task  at  hand.  Another 
key  requirement  that  justifies  the  use  of  data  fusion  is  low  false  alarms.  In  general,  there 
is  a  tradeoff  between  missed  detections  and  false  alarms,  which  is  greatly  influenced  by 
the  mission  or  operation  profile.  If  a  diagnostic  system  produces  excessive  false  alarms, 
personnel  will  likely  ignore  it,  resulting  in  an  unacceptably  high  number  of  missed 
detections.  However,  presently  data  fusion  is  rarely  employed  in  monitoring  systems, 
and  when  it  is  used,  it  is  usually  an  after-thought.  In  this  section,  we  describe  examples 
of  fault  diagnosis  employing  data  fusion  at  the  feature  and  decision  levels. 


5.5.1  Feature  Level  Fusion 

Vibration  monitoring  is  an  integral  part  of  Health  and  Usage  Monitoring  Systems 
(HUMS)  for  helicopters.  Changes  in  vibration  characteristics  at  different  locations  in  the 
helicopter  can  be  indicative  of  various  faults.  Signal  and  spectral  modeling  techniques 
are  used  to  characterize  signals  and  develop  features  for  detecting  various  faults  in  the 
machinery.  Adequate  modeling  of  the  signals  often  requires  large  model  orders, 
especially  due  to  the  presence  of  intermodulation  and  other  sources  of  noise.  However, 
for  fault  classification  and  localization,  it  is  usually  possible  to  derive  a  reduced  set  of 
features  through  various  types  of  transformations.  Previously,  such  an  approach  was 
demonstrated  with  the  Westland  helicopter  transmission  vibration  signal  data  set,  which 
consists  of  no-fault  and  seeded-fault  test  runs  of  a  CH-46E  aft  transmission  [34],  In  this 
section,  the  benefits  of  this  methodology  for  monitoring  of  helicopter  gearboxes  are 
demonstrated  using  seeded  fault  helicopter  data  for  an  H60  intermediate  gearbox  [22], 

The  data  used  for  the  evaluations  reported  herein  are  from  a  seeded  fault  test  of  an 
intermediate  gearbox  (IGB)  pinion  for  an  H60  helicopter.  The  data  was  acquired  under 
the  Helicopter  Integrated  Diagnostic  System  (HIDS)  Program  at  the  Naval  Air  Warfare 
Center  Aircraft  Division  in  Patuxent  River  NAS,  Maryland.  The  test  conducted  involved 
fault  propagation  on  an  IGB  pinion,  where  a  small  Electrical  Discharge  Machine  notch 
was  used  to  initiate  a  stress  riser  in  the  root  of  a  tooth.  A  crack  was  then  grown  from  the 
seeded  notch  by  running  the  test  rig  at  100%  tail  power  for  a  total  of  2  million  cycles 
Figure  5.6. 
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Figure  5.6:  Intermediate  Gearbox  Pinion  fault. 


Several  useful  techniques  have  been  developed  to  extract  features  from  the  vibration 
signature  [67],  Generally  these  features  are  more  stable  and  well  behaved  than  the  raw 
signature  data  itself.  In  addition,  the  features  constitute  a  reduced  data  set,  because 
one  feature  value  may  represent  an  entire  snapshot  of  data,  thus  facilitating  additional 
analysis  such  as  pattern  recognition  for  diagnostics  and  feature  tracking  for  prognostics. 
Moreover,  the  use  of  feature  values  instead  of  raw  vibration  data  will  become  extremely 
important  as  wireless  applications,  with  greater  bandwidth  restrictions,  become  more 
widely  used.  Figure  5.7  illustrates  an  example  of  the  processing  flow  for  feature 
extraction.  This  process  was  implemented  in  a  MATLAB-based  CBM  Toolbox 
developed  at  the  Penn  State  ARL. 


Signal 

Figure  5.7:  Processing  flow  for  vibration  signal  feature  extraction. 
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Classification  techniques  for  fault  identification  attempt  to  map  sensor  measurements  or 
feature  vectors  into  indicators  of  distinct  fault  conditions.  Such  a  mapping  must 
transform  the  data  or  feature  vectors  into  separable  groups  of  patterns  in  feature  space. 
That  is,  feature  vectors  that  represent  different  fault  classes  should  result  in  clusters  (or 
groupings),  which  are  widely  separated,  when  represented  in  feature  space.  This  is  not 
necessarily  an  easy  task  and  may  require  the  use  of  feature  transformation  techniques 
and  feature  selection.  The  underlying  assumption  for  such  an  undertaking  to  be 
successful  is  that  the  data  from  no-fault  condition  and  the  various  types  of  fault 
conditions  arise  from  different  distributions.  The  results  of  fault  severity  classification 
based  on  feature  level  fusion  are  shown  in  Figure  5.8.  Note  that  despite  the  variation  in 
feature  values,  the  classification  is  stable  due  to  the  benefit  of  fusion. 
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Figure  5.8:  Classification  results  over  the  duration  of  the  test  run. 


Previously,  benefit  of  feature  level  fusion  for  classification  among  several  fault  types 
was  shown  using  CH-46  aft  transmission  vibration  data.  Faults  with  greatly  differing 
criticality  (e.g.,  shaft  cracking  and  bearing  corrosion)  are  often  confused  due  to  similar 
symptoms  (see  Figure  5.9).  However,  using  feature  level  fusion  such  faults  are 
separated.  This  enhances  the  situation  awareness  and  also  maintenance  effectiveness. 
In  particular,  without  the  feature  level  fusion  the  rotorcraft  would  be  flagged  for 
maintenance  and  this  would  lead  to  unnecessary  troubleshooting  and  unnecessary 
maintenance  action.  Moreover,  the  vehicle  would  be  unavailable  longer.  On  the 
operational  side,  the  benefit  of  increased  awareness  is  fewer  aborted  missions  [33], 
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Figure  5.9:  Fault  Classification  using  CH-46  aft  transmission  multi-sensor 

vibration  signal  data. 

5. 5. 1.1  Decision  Level  Fusion 

The  application  of  data  fusion  techniques  to  condition  monitoring  of  complex  systems 
would  appear  to  provide  advantages  for  accurately  characterizing  the  state  of  the 
system.  To  date,  however,  only  a  few  attempts  have  been  made  to  develop  such 
systems.  McGonigal  [72]  compared  three  techniques  (neural  networks,  fuzzy  logic, 
and  rule-based  reasoning)  for  decision  level  fusion  of  vibration  data  for  the  mechanical 
diagnostic  test  bed.  The  benefit  of  decision  level  fusion  on  estimation  of  the  remaining 
useful  life  is  shown  in  Figure  5.10. 
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Figure  5.10:  Decision  level  fusion  for  RUL  estimation. 

Kozlowski  developed  a  feature-level  fusion  approach  for  battery  systems  that  proved  to 
be  very  robust  (see  the  discussion  in  Byington  and  Garga  [16]).  Erdley  [29]  tigated 
several  voting  schemes  for  data  fusion  for  the  Penn  State  mechanical  diagnostic  test 
bed,  and  showed  the  utility  of  fusion  methods  (see  Figure  5.11).  Finally,  Garga  [35] 
utilized  hybrid-reasoning  techniques  for  feature-level  and  decision-level  fusion. 


Number  of  sensors 

Figure  5.11:  Improved  fault  classification  performance  with  decision  level  fusion. 

The  benefit  of  HUMS  information  to  situation  awareness  was  recently  described  by 
Garga  et  al  for  a  rotorcraft  application  [33]  Figure  5.12  shows  the  types  of  information 
that  can  be  communicated  to  the  aircrew  and  the  maintenance  personnel  based  on  the 
HUMS  data.  In  this  development,  the  procedures  and  checklists  that  are  used  by  the 
aircrew  were  made  available  in  electronic  format.  As  a  result  the  appropriate  procedure 
and  checklist  were  provided  the  aircrew  based  on  the  specific  problem  that  developed  in 
the  scenario  being  demonstrated. 
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Figure  5.12:  Demonstration  of  HUMS  information  for  increased  aircrew  awareness. 


Various  types  of  knowledge  are  used  in  hybrid  reasoning  and  in  fault  diagnosis.  A 
FMECA  and  knowledge  elicited  from  the  field  personnel  are  typically  found  to  be  very 
useful.  Next,  a  study  is  described  that  provides  useful  information  about  the  top 
degraders  in  the  LAV. 


5.5.1 .2  LAV  Top  Degrader  Study 

A  study  Error!  Reference  source  not  found,  was  performed  to  identify  the  top 
degraders  of  the  US  Marine  Corps  Light  Armored  Vehicle  at  the  request  of  the  Program 
Management  office  for  LAV  (see  Figure  5.13).  The  top  ten  degraders  were  identified 
with  respect  to  their  effects  on  availability,  reliability  and  performance.  The  Penn  State 
Applied  Research  Laboratory  also  identified  opportunities  for  the  application  of  vehicle 
based  diagnostics  and  prognostics  that  would  mitigate  the  effect  of  the  principle 
degraders. 
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Propellers 

Figure  5.13:  The  LAV  at  PSU  ARL  with  the  locations  of  the  vibration  sensors. 
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The  methodology  used  to  determine  the  vehicle’s  top  degraders  consisted  of  three 
parts:  analysis  of  the  MIMMS  data  to  evaluate  which  parts  were  replaced  most  often, 
interviews  with  vehicle  maintainers  to  assess  issues  in  the  field  and  a  failures  modes 
and  effects  analysis  (FMEA)  that  was  developed  by  Penn  State  ARL  for  the  vehicle. 


The  analysis  indicated  that  the  top  degraders  to  vehicle  mobility  are: 

1 .  Differentials 

2.  Batteries 

3.  Planetary  Gear  Set  in  Wheel  Hubs 

4.  Alternator 

5.  Transfer  case 

6.  Seals 

7.  Fuel  Pump 

8.  Vehicle  Hydraulic  System 

9.  Diesel  Engine 

10.  Transmission 


When  a  simple  tally  of  the  number  of  replaced  parts  per  year  is  evaluated,  it  is  a 
straightforward  assessment  to  rank  the  top  vehicle  degrader  in  terms  of  mobility,  but  this 
assessment  is  not  complete.  Many  factors  must  be  taken  into  account,  such  as  ranking 
the  severity  of  the  consequences  of  failure  of  each  sub-system  upon  the  primary  vehicle 
function  of  mobility,  logistic  delay  time  for  obtaining  replacement  parts  and  the  ease  of 
diagnosing  and  isolating  faults  for  each  sub-system.  The  combination  of  these 
additional  factors  makes  it  more  difficult  to  conclude  that  one  system  is  the  clear 
outstanding  top  LAV  mobility  degrader.  It  is  clear  that  when  considering  all  of  the  data, 
three  sub-systems  stand  out  equally  as  the  top  degraders  related  to  the  operation  and 
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maintenance  of  the  LAV.  These  sub-systems  are  the  differentials,  batteries  and 
planetary  gear  sets  in  the  wheel  hubs. 

The  suggested  path  forward  from  the  results  of  this  analysis  is  to  apply  the  appropriate 
health  monitoring  technology  based  on  the  results  of  the  FMEA  to  the  top  two  to  three 
vehicle  degraders.  The  technology  can  then  be  field  tested  to  validate  the  benefits  from 
the  implementation  of  asset  health  monitoring  on  the  LAV. 

Analysis  Process 

The  methodology  for  identifying  the  vehicle  degraders  and  the  technology  for  vehicle 
health  monitoring  involves  a  combination  of  three  steps:  review  and  compile  parts 
ordered  records  (MIMMS  data),  conduct  interviews  with  experienced  maintainers  of  the 
LAV  and  perform  a  modified  failure  modes  and  effects  analysis  (FMEA). 

The  first  step  of  the  process  provides  a  method  for  identifying  the  ‘realistic’  top 
degraders  of  vehicle  operation  and  maintenance.  This  was  conducted  by  analyzing  the 
MIMMS  data  supplied  by  PM  LAV,  which  includes  the  parts  ordered  records.  In  order  to 
establish  the  scope  of  the  analysis,  the  primary  and  secondary  functions  of  the  vehicle 
must  be  defined.  The  primary  function  of  the  vehicle  is  to  transport  combat  ready 
Marines  and  the  vehicle  crew  members  to  their  mission  destination  over  land  and 
through  small  water  obstacles  in  a  safe  and  timely  manner.  The  LAV  also  has  many 
secondary  functions  that  are  dependant  upon  the  design  variant  of  the  vehicle.  The 
eight  LAV  design  variants  including  vehicle  designation,  number  of  vehicles  for  each 
designation  and  description  of  vehicle  function  is  shown  in  Table  5.3. 


Table  5.3:  LAV  Desi 

gn  Variants 

Designation 

Number 

Type 

LAV-25 

408 

Personnel  Carrier 

LAV-AT 

95 

Anti-Tank 

LAV-L 

94 

Logistics 

LAV-C2 

50 

Command  and  Control 

LAV-M 

50 

Mortar 

LAV-R 

45 

Maintenance  and  Recovery 

LAV-AD 

17 

Air  Defense 

MEWSS 

12 

Mobile  Electronic  Warfare  Support  System  , 

The  analysis  consisted  of  determining,  which  vehicle  components  are  most  critical  to 
the  primary  function  of  the  vehicle  as  well  as  which  components  were  replaced  most 
often.  Several  parts  such  as  nuts  and  bolts  have  a  high  replacement  rate  but  they  are 
not  necessarily  critical  to  the  mobility  of  the  vehicle.  The  focus  of  the  analysis  was 
directed  at  the  prime  mover,  the  drive  train  and  the  mobility  critical  subsystems  such  as 
the  hydraulic,  pneumatic  and  electrical  power  systems. 

The  MIMMS  data  consists  of  a  list  of  the  number  of  parts  ordered  each  year  from  1999 
through  2002  as  well  as  the  part  ordered  and  part  received  dates.  The  number  of  parts 
ordered  was  compiled  for  each  year  and  the  results  from  all  four  years  were  averaged 
to  provide  a  mean  value.  In  order  to  estimate  the  deadline  time  the  vehicles  may 
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encounter  due  to  the  time  it  takes  to  order  and  receive  parts,  the  logistic  delay  time  for 
each  component  or  sub-system  was  calculated.  Using  the  ordered/received  dates  a 
logistic  delay  value  in  days  was  estimated  (received  date  minus  ordered  date)  and  the 
average  of  these  values  over  the  four  years  was  also  determined.  Since  the  logistic 
delay  values  showed  a  significant  variation,  the  standard  deviation  of  the  values  was 
calculated  to  show  the  distribution  of  the  logistic  delay.  The  average  of  the  standard 
deviations  was  also  determined. 

The  next  step  of  the  analysis  process  involved  conducting  interviews  with  Marine  and 
civilian  contractor  maintenance  personnel  to  ascertain  which  components  contribute  the 
most  to  low  vehicle  reliability  and  availability.  The  interviews  were  focused  on  gaining 
perspective  about  maintainability  issues  associated  with  diagnosing  and  replacing 
vehicle  line  replaceable  units  (LRU).  The  data  gathered  from  the  interviews  was 
compared  to  the  parts  ordered  data  to  corroborate  the  information.  The  interviews  were 
conducted  at  three  locations  including:  the  Schoolhouse  at  Aberdeen  Proving  Grounds, 
Maryland,  the  Exercise  Support  Division  and  3rd  LAR  Bn.  at  Twenty  Nine  Palms, 
California  and  the  1st  LAR  Bn.  at  Camp  Pendleton,  California.  Questionnaires  were  also 
sent  to  PMO-LAV  at  Albany,  Georgia  and  the  2nd  LAR  Bn.  at  Camp  Lejeune,  North 
Carolina. 

The  third  step  of  the  process  provides  a  method  for  analyzing  the  detailed  degradation 
issues  and  identifying  diagnostic  and  prognostic  technology  for  each  degradation  failure 
mode.  The  FMEA  method  is  a  tool  for  identifying  and  evaluating  the  function  failure 
modes  (degraders)  of  a  system  as  well  as  how  to  detect  and  monitor  for  each  of  the 
failure  modes.  The  process  starts  by  describing  the  function  of  each  component  or  sub¬ 
system  and  then  listing  failure  modes  that  prevent  the  implementation  of  that  function. 
The  frequency  of  occurrence  or  the  likelihood  that  that  failure  mode  will  occur  is  based 
on  the  data  from  the  MIMMS  data.  The  consequences  of  the  failure  in  terms  of 
operational  availability  of  the  vehicle  and  maintenance  issues  for  each  component  must 
also  be  ranked  by  severity  level.  The  severity  levels  for  each  component  or  sub-system 
is  are  based  on  four  factors: 

1.  Diagnosis  and  Fault  Isolation  in  the  Field 

2.  Part  Availability  in  the  Field 

3.  Time  to  Repair  in  the  Field 

4.  Failure  Affect  on  Mission 

The  severity  ranking  is  the  sum  of  the  four  parameters  for  each  component  evaluated. 
The  ranking  ranges  from  0  to  40,  where  0  is  the  least  severe  consequences  and  40  is 
the  most  severe  consequences. 

The  symptoms  and  effects  of  each  failure  mode  are  also  listed  through  the  FMEA 
process.  The  symptoms  are  defined  as  events  that  can  be  observed  prior  to  the  failure 
mode  occurring  or  when  the  failure  mode  is  in  early  stages  of  development.  The  effects 
are  defined  as  events  that  are  a  direct  result  of  the  failure  mode  where  effects  in  ‘yellow’ 
are  downstream  failure  modes.  The  symptoms  and  effects  are  essentially  a  list  of 


47 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3) 


events  that  provide  an  indication  of  the  presence  of  a  fault  in  the  system.  The 
component  column  identifies  the  component  immediately  affected  by  the  failure  mode. 
The  sensors  column  lists  the  instrumentation  that  would  be  used  to  observe  or  detect 
the  symptom  or  effect  of  each  failure  mode.  The  sensor  component  column  indicates 
the  component  to  which  the  sensor  is  linked  or  located.  The  sensor  information  is  an 
addition  to  the  standard  FMEA  format  because  it  provides  important  information  for 
determining  how  the  indicators  of  the  failure  mode  should  be  monitored.  Finally,  the  last 
column  lists  the  algorithms,  techniques  and  technologies  that  can  be  used  with  each 
sensor  to  detect  and  diagnose  the  occurrence  of  each  failure  mode.  The  FMEA's  will  be 
used  as  a  guide  for  the  architecture  development  of  the  vehicle  health  monitoring 
system.  An  example  of  the  FMEA  format  from  the  LAV  degrader  study  is  shown  in 
Figure  5.14.  For  further  detail  see  [4], 
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Figure  5.14:  Battery  FMEA  developed 
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er  Study 

At  Penn  State  ARL,  a  demonstration  was  done  show  how  the  information  collected  on 
several  vehicles  can  be  communicated  upward  for  various  customers  for  command  and 
control  and  logistics  management  Figure  5.15.  Several  tabs  can  be  seen  at  the  top  of 
the  display:  (1)  Asset  visibility,  (2)  Status  &  Performance,  (3)  Condition  &  Health,  (4) 
VMS  system,  (5)  Trends,  (6)  Video,  and  (7)  Connections.  The  display  shows  asset 
identification,  position,  speed,  heading,  fuel  level,  etc.  for  several  vehicles  in  the  area  of 
interest.  These  are  based  on  the  GPS  information  communicated  by  the  vehicles 
regularly.  Under  other  tabs  information  relevant  to  that  category  is  presented.  Thus,  the 
desired  information  is  available  in  a  timely  manner  and  alerts  can  be  communicated 
without  delay.  More  details  can  also  be  accessed  by  querying  the  system  on  the 
appropriate  screen.  For  example,  under  Condition  &  Health  tab,  one  can  access 
indicators  that  are  used  for  determining  vehicle  health.  Such  information  is  updated  in 
real-time  and  significantly  increases  the  situation  awareness  and  mission  effectiveness. 
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Figure  5.15:  Vehicle  and  Systems  Health  Information. 


Further  details  about  data  fusion  and  fault  diagnosis  are  given  in  the  Appendix  7.4  on 
Sensor  Fusion  and  Fault  Diagnosis.  The  references  pertaining  to  this  chapter  are  also 
given  in  that  appendix  . 
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6  Marine  Corps  Equipment  Readiness  Information  Tool 
(MERIT)  Review 


MERIT  is  a  non  transactional  web  based  tool  currently  in  use  at  the  USMC.  Its  key 
functions  include  enabling  visualization  of  the  equipment  readiness  status  by  using 
detailed  supply  and  maintenance  information.  MERIT  transforms  the  maintenance  data 
into  relevant  information  that  provides  a  near  real  time  view  of  equipment  readiness.  It 
presents  a  comprehensive  Marine  Corps  readiness  posture  while  presenting  detailed 
information  about  the  availability  of  specific  parts.  It  contains  a  graphical  user  interface 
in  combination  with  a  readiness  analysis  tool.  It  essentially  automates  the  process  of 
developing  detailed  readiness  maps.  Thus  it  reduces  the  work  load  on  the  analysis 
experts. 

MERIT  uses  and  open  source  java-based  programming  technique.  The  delivery  method 
uses  a  web  browser  using  java  applet  running  on  a  server,  this  is  connected  to  the  data 
source  such  as  Oracle,  XML  or  delimited  text.  MERIT  also  uses  a  combination  of  filters, 
labels  and  search  tools  either  group  the  data  in  numerous  desired  ways  or  presenting 
multiple  calculations  for  current  and  historical  USMC  readiness  data.  It  also  uses 
different  color  schemes  for  representing  the  data  element  and  thus  enables  easy 
visualization. 

A  critical  review  of  the  MERIT  system  will  help  the  team  identify  the  different 
maintenance  data  that  the  system  is  currently  capturing.  It  will  also  help  the  team  review 
the  techniques  that  are  used  to  store/catalogue  the  data  elements.  Such  a  critical 
analysis  will  help  the  study  team  augment  the  type  of  data  captured  so  as  to  use  them 
in  the  proposed  transactional  system.  Further  review  and  analysis  of  MERIT  will  be 
performed  by  the  team  in  the  immediate  future.  Details  of  the  tasks  scheduled  in  this 
regard  are  mentioned  in  the  'Planned  work’  section  of  this  document. 
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7  Appendices 

7.1  Appendix  1  -  List  of  Actors 


Actor 

Description 

Commander  of  Company 

Commander  of  the  Company  in  the  field  who  has  read-only  access 
to  component  history  database  to  determine  health  status  of 
deployed  vehicles  and  sub-systems.  Company  is  the  2nd  from 
smallest  (between  Battalion  and  Division)  deployed  unit  in  the  field 

Commander  of  Division 

Commander  of  the  Division  in  the  field  who  has  read-only  access  to 
component  history  database  to  determine  health  status  of  deployed 
vehicles  and  sub-systems.  Division  is  below  Platoon  and  above 
Company  in  the  hierarchical  organization  of  deployed  soldiers.  (2nd 
from  the  largest) 

Commander  of  Platoon 

Commander  of  the  Platoon  in  the  field  who  has  read-only  access  to 
component  history  database  to  determine  health  status  of  deployed 
vehicles  and  sub-systems.  Platoon  is  the  largest  deployed  unit  in 
the  field. 

Commander  of  the 

Battalion 

Commander  of  the  Battalion  in  the  field  who  has  read-only  access 
to  component  history  database  to  determine  health  status  of 
deployed  vehicles  and  sub-systems.  Battalion  is  the  smallest 
(among  company,  division,  battalion  and  platoon)  deployed  unit  in 
the  field. 

Battalion  level  Active 
Passive  Sensor  Signal 
Analyst  (APSSA) 

System  OR  human  processing  and  analysis  of  the  sensor/  PDA 
signals  received  from  the  field.  Hub  of  all  activities/  decision  making 
at  Battalion  level.  Interfaced  with  Diagnostic  unit,  0  level  inventory 
database  and  component  history  database. 

Requestor  in  the  Vehicle 
(User/Non-User) 

Personnel  in  the  LAV  who  perform  diagnosis  of  subsystems, 
reporting  of  out  of  ordinary  events  and  day-to-day  maintenance 
operations  of  the  LAV  for  e.g.  mechanic,  driver,  turret  operator  etc 

Subsystem  Sensor 

Sensor  installed  on  various  subsystems  in  the  LAV  that  feed  a 
stream  of  data  to  the  LAV  system  processor  for  prognosis 
purposes. 

Maintenance  Person  at 
D-Level 

Personnel  at  D  level  maintenance  that  perform  actual  corrective, 
preventive  or  condition  based  maintenance  work  on  the  LAV 
subsystem/  component.  D-level  is  the  highest  level  among  the  3 
maintenance  levels  and  corresponds  roughly  to  the  MEF/  Sea  Base 
organizational  level.  Also  interfaces  with  Request  Management 
function  of  OA  processes. 

Maintenance  Person  at  1- 
Level 

Personnel  at  1  level  maintenance  that  perform  actual  corrective, 
preventive  or  condition  based  maintenance  work  on  the  LAV 
subsystem/  component,  l-level  is  the  middle  level  among  the  3 
maintenance  levels  and  corresponds  roughly  to  the  MEB 
organizational  level. 

Maintenance  Person  at 
O-Level 

Personnel  at  O  level  maintenance  that  perform  actual  corrective, 
preventive  or  condition  based  maintenance  work  on  the  LAV 
subsystem/  component.  O-level  is  the  lowest  level  among  the  3 
maintenance  levels  and  corresponds  roughly  to  the  Bn 
organizational  level. 

MEB  Level  Active 

Passive  Sensor  Signal 
Analyst  (APSSA) 

System  OR  human  processing  and  analysis  of  the  signals  received 
from  the  Battalion  level.  Hub  of  all  activities/  decision  making  at 
MEB  level.  Interfaced  with  Diagnostic  unit,  1  level  inventory 
database  and  component  history  database. 
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MEF  Level  Active 

Passive  Sensor  Signal 
Analyst  (APSSA) 

System  OR  human  processing  and  analysis  of  the  signals  received 
from  the  MEB  level.  Hub  of  all  activities/  decision  making  at  MEF 
level.  Interfaced  with  Diagnostic  unit,  D  level  inventory  database 
and  component  history  database. 

Distribution  Manager 

Manager  of  DM  functions.  Responsibilities  involve  managing  and 
planning  the  distribution  strategy  and  transportation  of  inventory 

Inventory  Manager 

Manager  of  IM  functions.  Responsibilities  include  managing  the 
inventory  strategies  after  planning  processes  are  determined. 

LCP  Manager 

Manager  of  LCP  functions.  He  is  located  at  enterprise  level.  The 
duty  of  LCP  manager  is  planning  and  designing  logistic  chain  to 
fulfill  customer's  demands. 

Maintenance  Manager 

Manager  of  MM  functions.  Responsibilities  include  scheduling  and 
reserving  specific  resources  to  support  overall  fulfillment 
requirements  for  maintenance  services.  In  addition,  the 
Maintenance  Operations  Management  function  will  also  adjust 
schedules  and  or  resources  according  to  feedback  from  the 
execution  function. 

Order  Manager 

Manager  of  OM  functions  including  routing,  coordinating,  tasking, 
and  tracking  customer  orders  through  fulfillment.  This  function 
works  by  receiving  requests  from  customers,  generating  customer 
orders  (based  on  requests)  and  initiating  the  fulfillment  of  products 
and  services.  In  addition,  OM  processes  communicate  order  status 
to  the  customer. 

Procurement  Manager 

Manager  of  PM  functions  that  include  making  decisions  to  ensure 
that  the  necessary  procurement  capacity  is  available  to  meet 
demand.  This  process  also  serves  to  coordinate  with  other  logistics 
capacity  management  functions  to  ensure  that  requirements  are 
understood  and  that  the  fulfillment  of  product  needs  to  customers 
can  be  coordinated,  measured,  evaluated  and  managed  to  meet 
expectations 

Request  Management 

Manager 

Manager  of  RM  functions  including  generation  and  approval  of 
customer  demands.  Basically,  it  works  by  validating  customer 
requirements  and  generating  requests  for  logistics  support 
(fulfillment  of  products  and  services)  if  required.  RM  receives 
requirements  from  within  the  customer  /  supported  unit;  prioritizes 
requirements,  sources  the  demand  internally  or  processes  the 
requirement  into  a  request  and  submits  the  request  to  be  created 
into  an  order. 

Warehouse  Manager 

Manager  of  WM  functions.  Includes  responsibilities  such  as 
planning  of  packing  and  shipping  items  for  fulfillment  of  customer 
orders  or  replenishment  of  inventories  at  other  locations  OR 
receiving  items  from  providers  (internal  and  external),  verifying  and 
recording  assets  received,  recording  and  reporting  discrepancies 
and  storing  the  items  for  the  fulfillment  of  anticipated  customer 
orders. 

Sea  Base  Level  Active 
Passive  Sensor  Signal 
Analyst  (APSSA) 

System  OR  human  processing  and  analysis  of  the  signals  received 
from  the  MEF  level.  Hub  of  all  activities/  decision  making  at  Sea 
Base  level.  Interfaced  with  Diagnostic  unit,  D  level  inventory 
database  and  component  history  database. 
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7.2  Appendix  2  -  Use  Case  Documentation 

Use  Case  1 :  Read  component  history  database/  View  diagnosis  results 

Precondition:  The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/ 
component  in  the  LAV  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details. 

Actors:  APSSA  at  Battalion  level,  APSSA  at  MEB  level,  APSSA  at  MEF  level,  APSSA  at  Sea  Base  level, 
Maintenance  person  at  O  level,  Maintenance  person  at  I  level,  Maintenance  person  at  D  level,  LAV 
requestor  (User  and  Non  user),  Commander  of  platoon  in  field,  Commander  of  division  in  field, 
Commander  of  company  in  field,  Commander  of  FSSG  in  field,  Commander  of  Battalion  in  field 

Goal:  To  allow  the  above  actors  involved  at  various  levels  to  log  into  the  component  history  database  and 
read  a  comprehensive  history  report  of  the  component  (or  sub  system  under  consideration)  including  past 
diagnosis  results,  component  specifications  and  other  details. 

Flow  of  events: 

1.  The  actor/s  mentioned  above  logs  into  the  component  history  database  (at  his  respective  level)  to  read 
component  history/  view  the  diagnosis  results. 

2.  System  asks  actor  for  the  subsystem/  component  and  LAV  id,  under  consideration. 

3.  Actor/s  provides  the  ID  to  the  system. 

4.  System  displays  the  read-only  component  history/  diagnosis  results  to  the  actor 

Alternative  Flows: 

None 

Related  Use-Cases:  None  (Stand  alone) 

Frequency  of  usage: 

Level  of  operation:  LAV,  Battalion,  MEB,  MEF,  Sea  Base,  FSSG,  Company,  Division,  Platoon,  O,  I  and 
D  maintenance  levels 

Data  Used:  Ids  of  Unit,  LAV  and  subsystem/  component. 

Data  Generated:  Read  only  report  of  component  details  and  history  e.g.  product  code  (numerical), 
criticality  index  (numerical),  expiry  date  (date  format),  past  diagnosis  result  including  dates  and  times 
(date-time  format),  resolution  (text)  etc. 

Algorithms  used:  Database  search  and  retrieval  of  LAV  component  details 
Decision  support  tools:  Display  of  results  (Front  end) 


Use  Case  2:  Prognosis  of  the  health  of  an  LAV 

Precondition:  System  has  been  carrying  out  the  prognosis  of  the  health  of  different  sub  systems  in  the 
LAV 
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Actors:  Requestors  in  the  LAV  (User/  Non  user)  e.g.  LAV  mechanic,  Bn  level  APSSA,  MEB  level  APSSA, 
MEF  level  APSSA,  Sea  Base  level  APSSA,  (Commanders  at  Company,  Division,  Platoon  and  FSSG 
levels) 

Goal:  To  attempt  to  monitor  the  health  of  an  LAV,  on  the  whole,  based  on  health  of  its  constituent 
subsystems 

Flow  of  events: 

1 .  Actors  at  levels  above  query  component  history  database  to  determine  health  of  an  LAV 

2.  System  processor  at  respective  levels  check  database  to  determine  all  the  critical  sub  systems  in  the 
LAV  and  further  the  health  of  each  of  those  critical  sub  systems  (based  of  prognosis  or  diagnosis 
status) 

3.  Draw  inference  about  health  of  LAV  based  on  reports  above 

Alternative  Flows: 

None. 

Related  Use-Cases:  Diagnosis  of  subsystem  at  LAV  level,  Diagnosis  of  subsystem  at  Bn  level,  Diagnosis 
of  subsystem  at  MEB  level,  Diagnosis  of  subsystem  at  MEF  level,  Diagnosis  of  subsystem  at  Sea  Base 
level 

Frequency  of  usage:  TBD 

Level  of  operation:  LAV,  Bn,  MEB,  MEF,  Sea  Base  (Company,  Division,  Platoon,  FSSG) 

Data  Used:  Unit  and  LAV  id’s  (numerical) 

Data  Generated:  Display  of  health  status  of  LAV  subsystems  (text),  their  criticality  indices  (numerical) 
and  health  status  of  LAV  on  the  whole  based  on  that  information  (text) 

Algorithms  used:  Retrieval  of  health  status  of  every  subsystem  in  the  LAV,  given  the  LAV  id,  and  further 
inferring  the  health  status  of  the  LAV  based  on  that  information 

Decision  support  tools:  Display  health  status  of  LAV,  on  the  whole,  based  on  criticality  of  sub  systems 
and  their  respective  health  status 


Use  Case  3:  Authenticate  received  field  signals 

Precondition:  Employment  of  some  wireless  technology  and  multiplexing  technique  for  communication 
between  signals  from  the  field  (sensor  data  stream  or  PDA)  and  the  APSSA  at  Bn  level.  (Sensor  data 
stream  to  be  uploaded  to  Bn  level  periodically  or  on  breach  of  thresholds).  Receiver  system  is  in  place  at 
the  APSSA  location  (Bn)  to  receive  the  signals  and  pre-process  it. 

Actors:  APSSA  (Bn  level) 

Goal:  To  authenticate  the  source  of  the  sensor  data  stream  or  PDA  form  from  the  field  to  make  sure  that 
it  originates  from  validated  LAVs /  personnel. 

Flow  of  events: 
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1.  Receiver  at  Bn  level  system  processor  uploads  sensor  data  stream  from  the  LAV  level  storage  when 
the  threshold  is  breached  (or  periodically  as  the  case  may  be)  OR  receives  the  PDA  signal  from  the 
LAV  mechanic 

2.  Bn  level  APSSA  down  converts/  demodulates/  decodes  received  signals  (wireless  transmission 
aspects) 

3.  Bn  level  APSSA  checks  platoon/  division/  unit  id  in  decoded  message  to  verify/  authenticate  sender 

4.  (If  successful)  Bn  level  APSSA  stores  data  in  Bn  level  database 

Alternative  Flows: 

5.  (If  not)  System  ignores  received  signal 

Related  Use-Cases:  Report  out  of  ordinary  event,  Process  PDA  form,  Diagnosis  of  subsystem  at  Bn 

Frequency  of  usage:  TBD 
Level  of  operation:  Bn 

Data  Used:  Ids  of  Platoon,  Company,  Division,  Battalion,  LAV  and  subsystem/  component  (numerical), 
subsystem  sensor  data  stream  or  PDA  form  (digitized) 

Data  Generated:  Dates  and  times  of  data  upload  (date-time  format),  volume  of  data  (numerical),  mileage 
of  LAV  (numerical),  details  of  subsystem/  component  that  is  source  of  data  stream  e.g.  product  code 
(numerical),  criticality  index  (numerical)  etc. 

Algorithms  used:  Authentication  procedure  to  validate  data  source,  Wireless  reception  and  decoding 
techniques 

Decision  support  tools:  Alert  to  Bn  APSSA  of  incoming  data  stream,  Authentication  procedure  status 
notification  to  Bn  APSSA 


Use  Case  4:  Process  PDA  form  at  Bn  level 

Precondition:  Received  PDA  signal  from  field  (Report  out  of  ordinary  event)  has  been  authenticated 
successfully,  decoded  and  passed  here. 

Actors:  APSSA  (Battalion  level) 

Goal:  To  attempt  to  analyze  the  information  received  from  the  PDA  that  gives  further  description  about 
the  failure  (or  impending  failure)  of  the  subsystem,  with  a  view  to  diagnose  the  problem  successfully 

Flow  of  events: 

4.  APSSA  at  Bn  level  analyzes  PDA  form  received  from  field  for  details  identifying  LAV,  sub  system, 
component  (if  data  available)  etc  for  purposes  of  diagnosis 

5.  APSSA  locates  LAV  and  sub  system  details  in  database  at  Bn  level 

6.  APSSA  time  stamps  PDA  signal  reception  and  records  received  information  in  database  at  Bn  level 

Alternative  Flows: 
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None 

Related  Use-Cases:  Report  out  of  ordinary  event,  Authenticate  received  field  signals,  Diagnosis  of 
subsystem  at  Bn 

Frequency  of  usage:  TBD 

Level  of  operation:  Battalion 

Data  Used:  Ids  of  LAV  and  subsystem/  component  (numerical),  Received  PDA  form  from  the  LAV  (Out  of 
ordinary  event  report)  (alphanumeric) 

Data  Generated:  Display  of  analysis  results  e.g.  nature  of  problem  (text),  potential  resolution  measures 
(text)  etc  and  relevant  component  details  e.g.  product  code  (numerical),  criticality  index  (numerical), 
expiry  date  (date  format) 

Algorithms  used:  Bn  level  database  search  and  retrieval  of  LAV  subsystem  data 
System  analysis  algorithm  of  PDA  form,  Database  update  on  information  received 

Decision  support  tools:  Display  of  analysis  results  (Front  end),  Alert  to  APSSA  (Bn  level)  of  analysis 
results/  potential  corrective  solutions 


Use  Case  5:  Escalate  diagnosis  from  Bn  to  MEB 

Precondition:  Wireless  communication  and  plug  &  play  facility,  and  inventory  flow  channel  is  in  place 
between  the  Bn  and  MEB  levels. 

Actors:  Bn  level  APSSA,  MEB  level  APSSA 

Goal:  To  upload  the  data  stream/  Bn  level  diagnosis  results  and  also  ship  faulty  subsystem/  component 
from  Bn  to  MEB  so  that  MEB  level  can  assist  in  the  diagnosis  process. 

Flow  of  events: 

1 .  (If  diagnosis  attempts  at  Bn  level  fail)  Bn  level  APSSA  uploads  data  stream/  supplementary  information 
and  ships  subsystem/  component  to  MEB  level 

Alternative  Flows: 

None 

Related  Use-Cases:  Diagnosis  of  subsystem  at  Bn  level,  Diagnosis  of  subsystem  at  MEB  level 

Frequency  of  usage:  TBD 
Level  of  operation:  Bn 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical) 

Data  Generated:  Results  of  diagnosis  attempts  at  Bn  level  (text)  and  subsystem  sensor  data  stream 
(digitized) 


Algorithms  used:  Data  uploads  on  manual  triggers  (Diagnosis  fails  at  Bn) 
Decision  support  tools:  Diagnosis  results  at  Bn  level 
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Use  Case  6:  Diagnosis  of  the  health  of  a  subsystem  at  Bn  level 

Precondition:  Subsystem  sensor  data  stream  from  LAV  has  been  uploaded  to  Bn  and  PDA  form  from 
LAV  mechanic  has  been  analyzed/  processed. 

Actors:  APSSA  (Battalion  level) 

Goal:  To  attempt  to  diagnose  the  health  of  a  LAV  subsystem  based  on  received  information  from  LAV 
(uploaded  data  stream  and  PDA  form  from  LAV  mechanic)  to  determine  component  that  has  failed/  will 
fail. 

Flow  of  events: 

1.  APSSA  (Bn  level)  retrieves  LAV  and  subsystem  information  from  the  Bn  database  (This  information 
would  originate  from  the  processed  form  (from  PDA  in  the  field)  and  sensor  data  stream  uploaded  to  the 
Bn  level  from  the  LAV  storage  database) 

2.  APSSA  (Bn  level)  studies  retrieved  information  and  determines  exact  nature  of  problem  and  resolution 
measures 

3.  APSSA  (Bn  level)  checks  O  level  inventory  database  to  see  if  it  has  capabilities  to  resolve  successfully 
(expertise  and  equipment) 

4.  (If  yes)  APSSA  (Bn  level)  triggers  use  case-  Trigger  maintenance  action  by 
O  level 

5.  System  records  above  action  in  database 

Alternative  Flows: 

4.  (If  no)  system  triggers  Use  case-  Escalate  diagnosis  to  MEB  level 

5.  System  records  above  action  in  database. 

Related  Use-Cases:  Escalate  diagnosis  to  MEB  level,  Process  PDA  form  at  Bn,  Trigger  maintenance 
action  by  O  level 

Frequency  of  usage:  TBD 

Level  of  operation:  Battalion 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical),  Received  PDA  form  from  the  LAV 
(Out  of  ordinary  event  report)  (text)  and  uploaded  data  stream  from  LAV  level  (digitized) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  results  of  diagnosis  by  Bn  APSSA  e.g.  exact  nature  of  problem  (text),  corrective  action 
taken/  to  be  taken  (text)  etc.. 

Algorithms  used:  Bn  level  database  search  and  retrieval  of  LAV  subsystem  data 
Database  update  on  entering  of  action  taken,  O  level  inventory  database  check 

Decision  support  tools:  Alert  to  O-level  maintenance  regarding  impending  maintenance  action,  Display 
results  of  O  level  inventory  check 
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Use  Case  7:  Trigger  maintenance  action  by  O-level 

Precondition:  After  the  diagnosis  of  the  health  of  an  LAV  subsystem  has  been  performed  successfully  at 
the  Battalion  level  (and  it  has  been  determined  that  O  level  can  resolve  problem)  this  use  case  is 
triggered 

Actors:  O-level  maintenance  personnel,  Bn  level  APSSA 

Goal:  To  trigger  the  initiation  of  maintenance  action  by  the  O  level  maintenance.  Trigger  given  by  the 
Battalion  level 

Flow  of  events: 

1.  Bn  level  APSSA  enters  SMRC  code  (escalation  aide-  O  level)  for  subsystem  corrective  action  to  be 
taken  at  O  level 

2.  Bn  level  APSSA  sends  faulty  subsystem/  component  to  O  level  and  notifies  it  about  incoming  shipment 

3.  Bn  level  APSSA  records  above  action  in  database 

Alternative  Flows: 

None 

Related  Use-Cases:  Diagnosis  of  subsystem  by  Bn  level 

Frequency  of  usage:  TBD 
Level  of  operation:  Bn 

Data  Used:  Data  stream  from  LAV  subsystem  sensors  (digitized)  and  diagnosis  results  at  Bn  level  (text), 
LAV  and  subsystem  id’s  (numerical) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  SMRC  code 

Algorithms  used:  Bn  database  update  of  action  taken 

Decision  support  tools:  Alert  to  O  level  maintenance  regarding  incoming  shipment 


Use  Case  8:  Query  a  sensor  (Bit/Byte  check) 

Precondition:  Employment  of  some  wireless  technology  and  multiplexing  technique  for  communication 
between  LAV  system  processor  and  the  APSSA  (Bn  level).  Transmitter  system  is  in  place  at  the  APSSA 
location  (Bn)  to  send  query  signal  to  the  LAV  system  processor.  Query  to  be  sent  only  if  normal  periodic 
upload  of  data  from  LAV  system  processor  to  Bn  level  does  not  take  place  for  a  particular  subsystem. 

Actors:  APSSA  (Battalion  level),  LAV  sensor 

Goal:  To  ping/  trigger  the  LAV  system  processor  to  upload  the  sensor  data  stream  of  the  “missing”  LAV 
subsystem  to  Bn  level. 

Flow  of  events: 
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7.  Bn  level  system  processor  checks  Bn  database  to  determine  the  time  stamp  on  the  last  reception 
from  a  particular  subsystem  sensor  emanating  from  the  LAV  level. 

8.  (If  pre-determined  time  limit  elapsed)  Bn  level  system  processor  retrieves  LAV,  subsystem  id  and 
criticality  index  from  database.  System  alerts  Bn  level  APSSA 

9.  Bn  level  system  processor  initiates  query  to  LAV  system  processor  about  “missing”  subsystem  sensor 
and  stamps  priority  code  on  query  (depending  on  criticality  index) 

10.  Bn  level  system  processor  queues  such  outgoing  queries  depending  on  the  priority  code 

1 1 .  Bn  level  system  processor  records  the  query  time  in  database 

12.  Bn  level  system  processor  transmits  query  signal 

Alternative  Flows: 

2.  (If  time  limit  not  elapsed)  System  rests 

Related  Use-Cases:  Upload  data  stream  periodically  from  LAV  to  Bn  level 
Frequency  of  usage:  Whenever  60  minute  uploads  do  not  take  place 

Level  of  operation:  Battalion 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical),  criticality  index  of  subsystem 
(numerical) 

Data  Generated:  Priority  code  to  be  stamped  on  query  (numerical)  ping  command  to  subsystem  sensor 
(alphanumeric) 

Algorithms  used:  Bn  level  database  monitoring  to  determine  any  “missing”  subsystem  sensors  (sensor 
signal  reception  overdue) 

Decision  support  tools:  Alert  to  Bn  level  APSSA  on  elapsing  of  time  limit  since  last  reception  (Bn  level) 


Use  Case  9:  Report  out  of  ordinary  event 

Precondition:  The  mechanic  (requestor)  in  the  LAV  has  detected  the  malfunctioning  sub  system  and 
determined  that  he  needs  assistance  from  Bn  level  mechanic  (either  ship  component  to  Bn  level  from 
LAV  level  or  ship  replacements  or  expertise  to  LAV  level  from  Bn  level) 

Actors:  LAV  requestor  (user/  non  user)  e.g.  LAV  mechanic 

Goal:  To  seek  assistance  from  Bn  level  in  troubleshooting/  diagnosis  of  the  faulty  sub  system  if  the  LAV 
mechanic  is  unable  to  troubleshoot  it  himself 

Flow  of  events: 

1.  The  requestor  in  the  LAV  (user/  non-user)  fills  PDA  form  describing  details  of  sub  system  abnormality 
observed  in  the  LAV.  (Contains  information  related  to  either  shipping  component  to  Bn  level  or  shipping 
replacements/  expertise  from  Bn  level-  Refer  use  case  Subsystem  troubleshooting  assistance  to  LAV 
mechanic/  Escalate  diagnosis  to  Bn) 
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2.  (If  system  assistance  needed  in  filling  form  by  non  user)  The  system  invokes  the  assistant  (Wizard). 

3.  The  system  prompts  the  information  that  is  needed  to  assist  the  non-user  in  filling  PDA  form 

4.  The  non-user  fills  the  form  and  submits  for  transmission  from  LAV  to  Bn 

Alternative  Flows: 

2.  (If  system  assistance  not  needed)  The  user  fills  the  form  and  submits  for  transmission  from  LAV  to  Bn 

Related  Use-Cases:  Diagnosis  of  subsystem  by  LAV  mechanic,  Subsystem  troubleshooting  assistance/ 
Escalate  diagnosis  to  Bn  from  LAV,  Authentication  of  received  signals  at  Bn 

Frequency  of  usage:  TBD 

Level  of  operation:  LAV 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical) 

Data  Generated:  Dates  and  times  of  reporting  (date-time  format),  mileage  of  LAV  (numerical),  description 
of  problem  (text),  failure  mode/  category  of  problem)  (text)  etc. 

Algorithms  used:  System  assistance  (user  prompts)  in  filling  PDA  form 

Decision  support  tools:  None.  (Personal  decision  by  LAV  mechanic) 


Use  Case  10:  Diagnosis  of  the  health  of  a  subsystem  at  LAV  level 

Precondition:  LAV  level  system  processor  has  extracted  appropriate  critical  parameters  from  sub  system 
sensor  data  stream  and  determined  that  they  fall  within  failure  range 

Actors:  Requestors  in  the  LAV  (User/  Non  user)  e.g.  LAV  mechanic 

Goal:  To  attempt  to  diagnose  the  health  of  a  LAV  subsystem  by  LAV  mechanic  based  on  subsystem 
sensor  data  stream,  to  determine  component  that  has  failed/  will  fail. 

Flow  of  events: 

1 .  LAV  level  system  processor  alerts  LAV  mechanic  about  the  problem  (Alarms) 

2.  LAV  system  processor  alerts  Battalion  level  system  processor  and  uploads  contents  of  LAV  black  box/ 
storage  to  the  Bn  level  database  (This  is  triggered  by  threshold  breach  only) 

3.  LAV  mechanic  attempts  to  trouble  shoot  the  problem. 

4.  (If  successful)  LAV  mechanic  records  corrective  action  in  database. 

(If  LAV  mechanic  determines  malfunctioning  component  but  does  not  have  resources  to  correct  it  on  the 
field,  he  ships  component  to  Bn  level.  LAV  mechanic  alerts  Bn  level  of  incoming  shipment.  Record  action 
in  LAV  database) 

Alternative  Flows: 

4.  (If  LAV  mechanic  unable  to  troubleshoot  problem)  he  triggers  Use  case-  Subsystem  trouble  shooting 
assistance/  Escalate  diagnosis  to  Bn  from  LAV.  Records  action  in  database. 
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Related  Use-Cases:  Prognosis  of  subsystem  at  LAV,  Subsystem  troubleshooting  assistance/  Escalate 
diagnosis  to  Bn  from  LAV,  Report  out  of  ordinary  event 

Frequency  of  usage:  TBD 

Level  of  operation:  LAV 

Data  Used:  Data  stream  from  subsystem  sensors  (analog),  LAV  and  subsystem  id’s  (numerical) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  results  of  diagnosis  by  mechanic  including  dates  and  times  of  action  taken  (date-time 
format),  exact  nature  of  problem  (text),  corrective  action  taken/  to  be  taken  (text)  etc. 

Algorithms  used:  Database  update  on  entering  of  action  taken,  Uploading  of  data  stream  to  Bn  level 

Decision  support  tools:  Alert  to  Bn  level  on  threshold  breach 


Use  Case  11:  Subsystem  troubleshooting  assistance  to  LAV  mechanic/  Escalate 
diagnosis  to  Bn  level 

Precondition:  LAV  mechanic  is  unable  to  troubleshoot  LAV  subsystem  malfunctioning  (sensor  data 
stream  having  breached  the  threshold  level)  on  his  own. 

Actors:  Bn  level  APSSA,  LAV  requestor  (User/  Non-user)  e.g.  LAV  mechanic 

Goal:  To  decide  flow  of  information/  inventory  for  LAV  subsystem  troubleshooting  assistance  viz.  Bn  to 
LAV  or  vice-versa.  Specifically,  whether  replacements/  expertise  will  be  shipped  from  Bn  to  LAV  or 
whether  faulty  subsystem/  component  will  be  shipped  to  Bn  from  LAV. 

Flow  of  events: 

12.  LAV  mechanic  determines  if  malfunctioning  sub  system  requires  Bn  level  mechanic  to  visit  LAV  or 
component  replacement  to  be  shipped  to  LAV  (or  if  subsystem/  component  should  be  shipped  to  Bn 
level) 

13.  (If  flow  required  from  Bn  to  LAV)  LAV  mechanic  sends  request  to  Bn  for  sending  mechanic  down  to 
LAV.  Trigger  Use  Case-  Report  out  of  ordinary  event  (for  requesting  such  assistance).  Record  above 
action  in  LAV  database. 

Alternative  Flows: 

2.  (If  flow  required  from  LAV  to  Bn)  LAV  mechanic  ships  subsystem/  component  to  Bn  level.  Also  trigger 
Use  Case-  Report  out  of  ordinary  event  (for  providing  further  information  on  faulty  subsystem)  Record 
request  in  LAV  database 

Related  Use-Cases:  Report  out  of  ordinary  event,  Diagnosis  of  subsystem  by  LAV  mechanic 

Frequency  of  usage:  TBD 
Level  of  operation:  LAV 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical),  Data  stream  from  subsystem 
sensors  (analog),  Diagnosis  results  by  LAV  mechanic  (text) 
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Data  Generated:  Tentative  corrective  measures  for  e.g.  mechanic  expertise  from  Bn  needed  or 
component  replacement  from  Bn  needed  and  level  at  which  malfunctioning  can  be  resolved  (i.e.  LAV  or 
Bn)  (All  text) 

Algorithms  used:  Database  update  of  information  recorded 

Decision  support  tools:  None  (Personal  decision  by  LAV  mechanic  on  scrutiny  of  subsystem) 


Use  Case  12:  Prognosis  of  the  health  of  a  subsystem  at  LAV  level 

Precondition:  LAV  level  system  processor  is  in  place  for  monitoring  the  data  stream  from  the  subsystem 
level  sensors  in  order  to  detect  breach  of  thresholds. 

Actors:  Requestors  in  the  LAV  (User/  Non  user)  e.g.  LAV  mechanic,  sensor 

Goal:  To  attempt  to  continuously  monitor  the  health  of  a  LAV  subsystem  based  on  subsystem  sensor 
data  stream 

Flow  of  events: 

1 .  LAV  system  processor  identifies  sub  system  from  which  the  sensor  data  is  received 

2.  LAV  system  processor  locates  the  sub  system  entry  in  LAV  black  box/  data  storage  device 

3.  LAV  system  processor  checks  database  to  determine  critical  parameters  and  failure  range  for  the  sub 
system 

4.  LAV  system  processor  extracts  appropriate  critical  parameters  from  sensor  data  stream 

5.  LAV  system  processor  checks  if  extracted  parameters  fall  in  failure  range 

6.  (If  yes)  LAV  system  processor  alerts  LAV  requestor  (User/  Non  user).  Refer  Use  Case:  Diagnosis  of 
subsystem  at  LAV  level 

7.  LAV  system  processor  time  stamps  sensor  data  stream  reception  and  records  it  as  well  as  other 
messages  e.g.  threshold  breach,  mechanic  alert  etc.  in  LAV  black  box/  data  storage  device 

Alternative  Flows: 

6.  (If  no)  LAV  system  processor  continues  recording  data  stream 
Related  Use-Cases:  Diagnosis  of  subsystem  at  LAV  level 

Frequency  of  usage:  TBD 
Level  of  operation:  LAV 

Data  Used:  Data  stream  from  subsystem  sensors  (analog),  critical  parameters  for  a  particular  sub  system 
and  its  threshold  values  (numerical),  LAV  and  subsystem  id’s  (numerical) 

Data  Generated:  Visual  representations  of  the  critical  parameters  being  monitored  in  the  sensor  data 
stream  (analog)  and  health  status  messages  (Well/  Fail)  depending  on  breach  of  thresholds  (text) 
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Algorithms  used:  Threshold  detection  in  subsystem  sensor  data  stream,  Data  stream  storage  in  LAV 
database,  Database  search  and  retrieval  of  subsystem  details,  Extraction  of  critical  parameters  from 
sensor  data  stream 

Decision  support  tools:  Visual  representations  of  the  critical  parameters  being  monitored  in  the  sensor 
data  stream  (Front  end)  and  other  subsystem  details  to  LAV  mechanic,  Alert  to  LAV  mechanic  when 
breach  occurs 


Use  Case  13:  Upload  data  stream  periodically  from  LAV  to  Bn 

Precondition:  Wireless  communication  facility  is  in  place  between  the  LAV  and  Bn  level  system 
processors. 

Actors:  Bn  level  APSSA 

Goal:  To  upload  the  data  stream  from  system  processor  at  LAV  level  to  Bn  level  so  that  Bn  level  can 
assist  in  the  diagnosis  process. 

Flow  of  events: 

1 .  LAV  level  system  processor  uploads  data  to  Bn  level  at  the  appropriate  periodic  time  intervals 

2.  System  records  above  action/s  in  LAV  database 

Alternative  Flows: 

None 

Related  Use-Cases:  None 
Frequency  of  usage:  60  minute  intervals 
Level  of  operation:  LAV 

Data  Used:  Ids  of  unit,  LAV  and  subsystem  (numerical),  pre-determined  period  of  data  uploads  (time)  e.g. 
60  minutes 

Data  Generated:  Data  stream  from  the  subsystem  sensor  (digitized  analog),  subsystem  details  e.g. 
product  code  (numerical),  criticality  index  (numerical),  recent  actions  taken  (text),  health  status  (text) 

Algorithms  used:  Periodic  self-triggers  for  data  uploads 

Decision  support  tools:  None 


Use  Case  14:  Take  Condition-Based  Maintenance  action  at  appropriate  level 

Precondition:  The  APSSA  at  the  appropriate  organizational  level  triggers  initiation  of  maintenance  action 
at  corresponding  maintenance  level  based  on  diagnostic  result  of  subsystem  from  particular  LAV 

Actor(s):  Maintenance  person  at  appropriate  level,  APSSA  at  corresponding  level,  RM  Manager 
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Goal:  To  successfully  perform  condition  based  maintenance  action  based  on  information  given. 

Flow  of  events 

1 .  The  APSSA  alerts  the  maintenance  person  of  approaching  LAV 

2.  The  maintenance  person  queries  information  of  the  LAV  component  that  needs  to  be  repaired  from 
component  history  database 

3.  The  maintenance  person  checks  the  database  if  the  component  is  available 

4.  (If  yes)  The  maintenance  person  performs  the  maintenance  actions 

Alternative  Flows: 

4.  (If  no)  Maintenance  person  triggers  the  request  for  the  component  to  the  RM  system 

Related  Use  Cases:  Trigger  maintenance  action  by  O/l/D  level,  Report  the  maintenance  action  at 
appropriate  level,  Trigger  request  management. 

Frequency:  TBD 

Level  of  Operation:  Battalion/  MEB /  MEF /  Sea  Base  Level 

Data  used:  Historical  data  of  the  component  (text),  Recommendation  from  the  APSSA  (text) 

Data  Generated:  Ordering  status  for  the  component  (text),  maintenance  action  status  (text) 

Algorithm  Used:  Query  for  historical  data  from  database,  check  the  availability  of  the  component. 
Decision  Support  Tools:  The  availability  of  the  components. 


Use  Case  15:  Report  the  Maintenance  Action  at  appropriate  level 

Precondition:  After  the  maintenance  has  been  performed,  the  maintenance  person  at  the  maintenance 
level  is  ready  to  record  the  action  taken  into  the  system  (GUI  display). 

Actors:  Maintenance  person  at  appropriate  level,  APSSA  person  at  corresponding  organizational  level 
Goal:  To  successfully  record  the  maintenance  action  as  a  reference  for  the  future. 

Flow  of  events 

1.  The  component  history  database  asks  for  the  ID  and  password  from  the  maintenance  person  before 
recording  the  maintenance  action 

2.  If  (password  =  correct)  Database  displays  the  form  to  be  filled  by  the  mechanic  about  the 
maintenance  activity. 

3.  Database  stores  information  that  is  entered  by  the  maintenance  person 

Alternative  Flows: 
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2.  If  (password  =  incorrect)  ask  the  user  to  re-enter 

Related  Use  Cases:  Take  the  corrective  maintenance  action  at  appropriate  level,  Take  the  preventive 
maintenance  action  at  appropriate  level,  Take  condition  based  maintenance  action  at  appropriate  level 

Frequency:  TBD 

Level  of  Operation:  Bn/  MEB /  MEF/  Sea  Base 
Data  Used:  User  ID  and  Password  (alphanumeric) 

Data  generated:  Maintenance  action  status  (text) 

Algorithm  Used:  Database  update  of  action  taken 

Decision  Support  Tools:  Maintenance  action  status  to  be  recorded 


Use  Case  16:  Take  the  corrective  maintenance  action  at  appropriate  level 

Precondition:  The  APSSA  at  appropriate  organizational  level  triggers  initiation  of  maintenance  action  at 
corresponding  level  based  on  diagnostic  result  of  subsystem  from  particular  LAV. 

Actor(s):  Maintenance  person  at  appropriate  level,  APSSA  at  corresponding  organizational  level,  RM 
manager 

Goal:  To  successfully  perform  corrective  maintenance  action  based  on  information  given. 

Flow  of  events: 

1.  The  APSSA  at  appropriate  level  alerts  the  maintenance  person  at  corresponding  level  of  required 
service  (incoming  shipment) 

2.  The  maintenance  person  queries  information  of  the  LAV  component/  subsystem  that  needs  to  be 
repaired  from  the  component  history  database 

3.  The  maintenance  person  checks  if  necessary  tools  (or  replacements)  are  available 

4.  (If  yes)  Maintenance  person  performs  the  maintenance  actions 

Alternative  Flows: 

5.  (If  no)  Maintenance  person  triggers  the  request  for  the  component  to  the  RM  Manager 

Related  Use  Cases:  Trigger  maintenance  action  by  O/l/D  levels,  Report  the  maintenance  action  at 
appropriate  level,  Trigger  request  management. 

Frequency:  TBD 

Level  of  operation:  Battalion/  MEB /  MEF/  Sea  Base  level 

Data  used:  Historical  data  of  the  component  (text),  Diagnosis  results  from  APSSA  (text), 
Recommendation  from  the  APSSA  (text),  Availability  of  the  component  at  each  level  (various). 
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Data  Generated:  Ordering  status  for  the  component  (text),  maintenance  action  status  (text) 
Algorithm  used:  Query  for  historical  data  from  database,  check  the  availability  of  the  component. 
Decision  support  tools:  Availability  of  the  components. 


Use  Case  17:  Trigger  request  management 

Precondition:  The  mechanics  at  particular  maintenance  level  checks  the  availability  of  the  component 
that  needs  to  be  repaired  or  changed. 

Actors:  Maintenance  person  at  O  level,  Maintenance  person  at  I  level,  Maintenance  person  at  D  level, 
Request  Management  Manager 

Goal:  To  support  the  needs  of  components  by  the  mechanics  at  a  particular  level  of  maintenance. 

Flow  of  events 

1.  The  mechanic  in  particular  maintenance  level  check  the  availability  of  the  component  in  the 
warehouse  or  through  the  component  availability  database 

2.  If  (component  =  available)  the  mechanic  takes  the  component  from  the  warehouse  and  update 
the  remaining  number  of  components  into  the  inventory  database. 

Alternative  Flows: 

1.  If  (component  =  unavailable)  the  mechanic  requests  for  the  component  online  to  the  Request 
Management  Manager. 

2.  The  Request  Management  Manager  updates  the  order  activity  into  the  inventory  database. 

Related  Use  Cases:  Take  the  Corrective  Maintenance  Action  (O  level),  Take  the  Corrective  Maintenance 
Action  (I  level),  Take  the  Corrective  Maintenance  Action  (D  level),  Condition  Based  Maintenance  Action 
(0  level),  Condition  Based  Maintenance  Action  (I  level),  Condition  Based  Maintenance  Action  (D  level), 
Take  the  Preventive  Maintenance  Action  (O  level),  Take  the  Preventive  Maintenance  Action  (I  level) 

Frequency:  TBD 

Level  of  Operation:  Battalion  Level,  MEB  level,  MEF  level 
Data  Used:  the  availability  of  the  component  at  particular  level 
Data  generated:  the  remaining  number  of  the  components. 

Algorithm  Used:  request  for  the  availability  of  the  component,  upload  the  remain  number  of  the 
component  into  the  inventory  database 

Decision  Support  Tools:  display  the  availability  of  the  particular  component  at  particular  level. 
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Use  Case  18:  Take  the  preventive  maintenance  action  at  appropriate  level 

Precondition:  APSSA  at  Bn/  MEB  level  reads  component  history/  diagnosis  results  from  database.  Then 
APSSA  then  triggers  the  preventive  maintenance  action  at  the  corresponding  maintenance  level  (O/l). 

Actor(s):  Maintenance  person  at  0/1  level,  APSSA  at  corresponding  level  (Bn/  MEB),  RM  Manager 

Goal:  To  successfully  perform  preventive  maintenance  action  based  on  historical  information  of 
component/  subsystem 

Flow  of  events 

1.  The  APSSA  alerts  the  maintenance  person  of  preventive  action  to  be  taken  on  a  particular 
subsystem/  component  (based  on  history  data) 

2.  The  maintenance  person  queries  information  of  the  LAV  component  that  need  to  be  repaired  from 
component  history  database 

3.  Maintenance  person  rechecks  if  maintenance  action  required 

4.  (If  yes)  The  maintenance  person  checks  if  tools/  replacements  available 

5.  (If  yes)  The  maintenance  person  performs  the  preventive  maintenance  actions 

Alternative  Flows: 

4.  (If  no)  No  further  action 

5.  (If  no)  Maintenance  person  triggers  the  request  for  the  component  to  the  RM  manager 

Related  Use  Cases:  View  diagnosis  result/  read  component  history  database,  Report  the  maintenance 
action  at  appropriate  level,  Trigger  request  management,  Trigger  maintenance  action  by  0/1  levels 

Frequency:  TBD 

Level  of  operation:  Battalion/  MEB 

Data  used:  Historical  data  of  the  component  (text),  Recommendation  from  the  APSSA  (text),  Availability 
of  the  component  at  each  level  (text) 

Data  Generated:  Ordering  status  for  the  component  (text),  the  maintenance  action  status  (text) 
Algorithms  Used:  Query  for  historical  data  from  database,  check  the  availability  of  the  component. 
Decision  Support  Tools:  The  availability  of  the  component 


Use  Case  19:  Diagnosis  of  the  health  of  a  subsystem  at  MEB  level 

Precondition:  The  Bn  level  has  diagnosed  the  subsystem  and  determined  that  it  needs  to  be  escalated 
to  the  MEB  level  as  it  (Bn  and  O  levels)  do  not  have  sufficient  resources  to  successfully  resolve  the 
problem 

Actors:  MEB  level  APSSA 


67 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3] 


Goal:  To  attempt  to  diagnose  the  health  of  a  subsystem  at  MEB  level  based  on  received  information  from 
LAV  and  Bn  level  to  determine  component  that  has  failed/  will  fail 

Flow  of  events: 

1.  APSSA  (MEB  level)  retrieves  LAV  and  subsystem  information  from  the  MEB  database  (This  would 
originate  from  the  consolidated  information  from  Bn  and  LAV  levels) 

2.  APSSA  (MEB  level)  studies  retrieved  information  and  determines  exact  nature  of  problem  and 
resolution  measures 

3.  APSSA  (MEB  level)  checks  I  level  inventory  database  to  see  if  it  has  capabilities  to  resolve 
successfully  (expertise  and  equipment) 

4.  (If  yes)  APSSA  (MEB  level)  triggers  use  case-  Trigger  maintenance  action  by 
I  level 

5.  System  records  above  action  in  database 

Alternative  Flows: 

4.  (If  no)  system  triggers  Use  case-  Escalate  diagnosis  to  MEF  level 

5.  System  records  above  action  in  database. 

Related  Use-Cases:  Escalate  diagnosis  to  MEF  level  from  MEB,  Trigger  maintenance  action  by  I  level, 
Escalate  diagnosis  to  MEB  level  from  Bn 

Frequency  of  usage:  TBD 

Level  of  operation:  MEB 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical),  Consolidated  information  from  Bn 
and  LAV  levels  (numerical,  digitized  and  text) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  results  of  diagnosis  by  MEB  APSSA  e.g.  exact  nature  of  problem  (text),  corrective 
action  taken/  to  be  taken  (text)  etc.. 

Algorithms  used:  MEB  level  database  search  and  retrieval  of  LAV  subsystem  data 
Database  update  on  entering  of  action  taken,  I  level  inventory  database  check 

Decision  support  tools:  Alert  to  l-level  maintenance  regarding  impending  maintenance  action,  Display 
results  of  I  level  inventory  check 


Use  Case  20:  Trigger  maintenance  action  by  l-level 

Precondition:  After  the  diagnosis  of  the  health  of  an  LAV  subsystem  has  been  performed  successfully  at 
the  MEB  level  (and  it  has  been  determined  that  I  level  can  resolve  problem)  this  use  case  is  triggered 

Actors:  l-level  maintenance  personnel,  MEB  level  APSSA 

Goal:  To  trigger  the  initiation  of  maintenance  action  by  the  I  level  maintenance.  Trigger  given  by  the  MEB 
level 
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Flow  of  events: 

1.  MEB  level  APSSA  enters  SMRC  code  (escalation  aide-  I  level)  for  subsystem  corrective  action  to  be 
taken  at  I  level 

2.  MEB  level  APSSA  sends  faulty  subsystem/  component  to  I  level  and  notifies  it  about  incoming 
shipment 

3.  MEB  level  APSSA  records  above  action  in  database 

Alternative  Flows: 

None 

Related  Use-Cases:  Diagnosis  of  subsystem  by  MEB  level 

Frequency  of  usage:  TBD 
Level  of  operation:  MEB 

Data  Used:  Data  stream  from  LAV  subsystem  sensors  (digitized)  and  diagnosis  results  at  MEB  level 
(text),  LAV  and  subsystem  id’s  (numerical) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  SMRC  code 

Algorithms  used:  MEB  database  update  of  action  taken 

Decision  support  tools:  Alert  to  I  level  maintenance  regarding  incoming  shipment 


Use  Case  21:  Trigger  maintenance  action  by  D-level 

Precondition:  After  the  diagnosis  of  the  health  of  an  LAV  subsystem  has  been  performed  successfully  at 
the  MEF/  Sea  Base  level  (and  it  has  been  determined  that  D  level  can  resolve  problem)  this  use  case  is 
triggered 

Actors:  D-level  maintenance  personnel,  MEF  level  APSSA,  Sea  Base  level  APSSA 

Goal:  To  trigger  the  initiation  of  maintenance  action  by  the  D  level  maintenance.  Trigger  given  by  the 
MEF/  Sea  Base  levels 

Flow  of  events: 

1.  MEF/  Sea  Base  level  APSSA  enters  SMRC  code  (escalation  aide-  D  level)  for  subsystem  corrective 
action  to  be  taken  at  D  level 

2.  MEF/  Sea  Base  level  APSSA  sends  faulty  subsystem/  component  to  D  level  and  notifies  it  about 
incoming  shipment 

3.  MEF/  Sea  Base  level  APSSA  records  above  action  in  database 

Alternative  Flows: 

None 

Related  Use-Cases:  Diagnosis  of  subsystem  by  MEF  level/  Diagnosis  of  subsystem  at  Sea  Base  level 
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Frequency  of  usage:  TBD 

Level  of  operation:  MEF  or  Sea  Base 

Data  Used:  Data  stream  from  LAV  subsystem  sensors  (digitized)  and  diagnosis  results  at  MEF/  Sea 
Base  level  (text),  LAV  and  subsystem  id’s  (numerical) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  SMRC  code 

Algorithms  used:  MEF  database  update  of  action  taken/  Sea  Base  database  update  of  action  taken 
Decision  support  tools:  Alert  to  D  level  maintenance  regarding  incoming  shipment 


Use  Case  22:  Diagnosis  of  the  health  of  a  subsystem  at  MEF  level 

Precondition:  The  MEB  level  has  diagnosed  the  subsystem  and  determined  that  it  needs  to  be  escalated 
to  the  MEF  level  as  it  (MEB  and  I  levels)  do  not  have  sufficient  resources  to  successfully  resolve  the 
problem 

Actors:  MEF  level  APSSA 

Goal:  To  attempt  to  diagnose  the  health  of  a  subsystem  at  MEF  level  based  on  received  information  from 
LAV,  Bn  and  MEB  levels  to  determine  component  that  has  failed/  will  fail 

Flow  of  events: 

1.  APSSA  (MEF  level)  retrieves  LAV  and  subsystem  information  from  the  MEF  database  (This  would 
originate  from  the  consolidated  information  from  MEB,  Bn  and  LAV  levels) 

2.  APSSA  (MEF  level)  studies  retrieved  information  and  determines  exact  nature  of  problem  and 
resolution  measures 

3.  APSSA  (MEF  level)  checks  D  level  inventory  database  to  see  if  it  has  capabilities  to  resolve 
successfully  (expertise  and  equipment) 

4.  (If  yes)  APSSA  (MEF  level)  triggers  use  case-  Trigger  maintenance  action  by 
D  level 

5.  System  records  above  action  in  database 

Alternative  Flows: 

4.  (If  no)  system  triggers  Use  case-  Escalate  diagnosis  to  Sea  Base  level 

5.  System  records  above  action  in  database. 

Related  Use-Cases:  Escalate  diagnosis  to  MEF  level  from  MEB,  Trigger  maintenance  action  by  D  level, 
Escalate  diagnosis  to  Sea  Base  level  from  MEF 

Frequency  of  usage:  TBD 

Level  of  operation:  MEB 
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Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical),  Consolidated  information  from  MEB, 
Bn  and  LAV  levels  (numerical,  digitized  and  text) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  results  of  diagnosis  by  MEF  APSSA  e.g.  exact  nature  of  problem  (text),  corrective 
action  taken/  to  be  taken  (text)  etc.. 

Algorithms  used:  MEF  level  database  search  and  retrieval  of  LAV  subsystem  data 
Database  update  on  entering  of  action  taken,  D  level  inventory  database  check 

Decision  support  tools:  Alert  to  D-level  maintenance  regarding  impending  maintenance  action,  Display 
results  of  D  level  inventory  check 


Use  Case  23:  Escalate  diagnosis  from  MEB  to  MEF 

Precondition:  Wireless  communication  and  plug  &  play  facility,  and  inventory  flow  channel  is  in  place 
between  the  MEB  and  MEF  levels. 

Actors:  MEF  level  APSSA,  MEB  level  APSSA 

Goal:  To  upload  the  data  stream/  MEB  level  diagnosis  results  and  also  ship  faulty  subsystem/  component 
from  MEB  to  MEF  so  that  MEF  level  can  assist  in  the  diagnosis  process. 

Flow  of  events: 

1.  (If  diagnosis  attempts  at  MEB  level  fail)  MEB  level  APSSA  uploads  data  stream/  supplementary 
information  and  ships  subsystem/  component  to  MEF  level 

Alternative  Flows: 

None 

Related  Use-Cases:  Diagnosis  of  subsystem  at  MEB  level,  Diagnosis  of  subsystem  at  MEF  level 

Frequency  of  usage:  TBD 
Level  of  operation:  MEB 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical) 

Data  Generated:  Results  of  diagnosis  attempts  at  MEB  level  (text)  and  subsystem  sensor  data  stream 
(digitized) 

Algorithms  used:  Data  uploads  on  manual  triggers  (Diagnosis  fails  at  MEB) 

Decision  support  tools:  Diagnosis  results  at  MEB  level 


Use  Case  24:  Trigger  request  management 

Precondition:  The  mechanics  at  particular  maintenance  level  checks  the  availability  of  the  component 
that  needs  to  be  repaired  or  changed. 

Actors:  Maintenance  person  at  O  level,  Maintenance  person  at  I  level,  Maintenance  person  at  D  level, 
Request  Management  Manager 
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Goal:  To  support  the  needs  of  components  by  the  mechanics  at  a  particular  level  of  maintenance. 

Flow  of  events 

3.  The  mechanic  in  particular  maintenance  level  check  the  availability  of  the  component  in  the 
warehouse  or  through  the  component  availability  database 

4.  If  (component  =  available)  the  mechanic  takes  the  component  from  the  warehouse  and  update 
the  remaining  number  of  components  into  the  inventory  database. 

Alternative  Flows: 

3.  If  (component  =  unavailable)  the  mechanic  requests  for  the  component  online  to  the  Request 
Management  Manager 

4.  The  Request  Management  Manager  updates  the  order  activity  into  the  inventory  database. 

Related  Use  Cases:  Take  the  Corrective  Maintenance  Action  (O  level),  Take  the  Corrective  Maintenance 
Action  (I  level),  Take  the  Corrective  Maintenance  Action  (D  level),  Condition  Based  Maintenance  Action 
(O  level),  Condition  Based  Maintenance  Action  (I  level),  Condition  Based  Maintenance  Action  (D  level), 
Take  the  Preventive  Maintenance  Action  (O  level),  Take  the  Preventive  Maintenance  Action  (I  level) 

Frequency:  TBD 

Level  of  Operation:  Battalion  Level,  MEB  level,  MEF  level 
Data  Used:  the  availability  of  the  component  at  particular  level 
Data  generated:  the  remaining  number  of  the  components. 

Algorithm  Used:  request  for  the  availability  of  the  component,  upload  the  remain  number  of  the 
component  into  the  inventory  database 

Decision  Support  Tools:  display  the  availability  of  the  particular  component  at  particular  level. 


Use  Case  25:  Diagnosis  of  the  health  of  a  subsystem  at  Sea  Base  level 

Precondition:  The  MEF  level  has  diagnosed  the  subsystem  and  determined  that  it  needs  to  be  escalated 
to  the  Sea  Base  level  as  it  (MEF  and  D  levels)  do  not  have  sufficient  resources  to  successfully  resolve  the 
problem 

Actors:  Sea  Base  level  APSSA 

Goal:  To  attempt  to  diagnose  the  health  of  a  subsystem  at  Sea  Base  level  based  on  received  information 
from  LAV,  Bn,  MEB  and  MEF  levels  to  determine  component  that  has  failed/  will  fail 

Flow  of  events: 

1.  APSSA  (Sea  Base  level)  retrieves  LAV  and  subsystem  information  from  the  Sea  Base  database  (This 
would  originate  from  the  consolidated  information  from  MEB,  MEF,  Bn  and  LAV  levels) 

2.  APSSA  (Sea  Base  level)  studies  retrieved  information  and  determines  exact  nature  of  problem  and 
resolution  measures 
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3.  APSSA  (Sea  Base  level)  checks  D  level  inventory  database  to  see  if  it  has  capabilities  to  resolve 
successfully  (expertise  and  equipment) 

4.  (If  yes)  APSSA  (Sea  Base  level)  triggers  use  case-  Trigger  maintenance  action  by 
D  level 

5.  APSSA  (Sea  Base  level)  records  above  action  in  database 

Alternative  Flows: 

4.  (If  no)  system  triggers  Use  case-  Trigger  Request  Management  (OA  processes)  to  external  suppliers 
SI  and  Sn 

5.  System  records  above  action  in  database. 

Related  Use-Cases:  Trigger  maintenance  action  by  D  level,  Escalate  diagnosis  to  Sea  Base  level  from 
MEF,  Trigger  Request  Management  to  external  suppliers 

Frequency  of  usage:  TBD 

Level  of  operation:  Sea  Base 

Data  Used:  Ids  of  unit,  LAV  and  subsystem/  component  (numerical),  Consolidated  information  from  MEF, 
MEB,  Bn  and  LAV  levels  (numerical,  digitized  and  text) 

Data  Generated:  Subsystem  details  e.g.  product  code  (numerical),  criticality  index  (numerical),  expiry 
date  (date  format),  results  of  diagnosis  by  Sea  Base  APSSA  e.g.  exact  nature  of  problem  (text), 
corrective  action  taken/  to  be  taken  (text)  etc. 

Algorithms  used:  Sea  Base  level  database  search  and  retrieval  of  LAV  subsystem  data 
Database  update  on  entering  of  action  taken,  D  level  inventory  database  check 

Decision  support  tools:  Alert  to  D-level  maintenance  regarding  impending  maintenance  action,  Display 
results  of  D  level  inventory  check 
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7.3  Appendix  3  -  Data  Mining 

Data  mining,  the  extraction  of  hidden  predictive  information  from  large  databases,  is  a  powerful  new 
technology  with  great  potential  to  help  organizations  focus  on  the  most  important  information  in  their  data 
warehouses.  Data  mining  tools  predict  future  trends  and  behaviors,  allowing  businesses  to  make 
proactive,  knowledge-driven  decision  supports.  The  automated,  prospective  analyses  offered  by  data 
mining  move  beyond  the  analyses  of  past  events  provided  by  retrospective  tools  typical  of  decision 
support  systems.  Data  mining  tools  can  answer  business  and  strategy  questions  that  traditionally  were 
time  consuming  to  resolve. 

7.3.1  The  Foundations  and  Scope  of  Data  Mining 

Data  mining  techniques  are  the  result  of  a  long  process  of  research  and  product  development.  This 
evolution  began  when  business  data  was  first  stored  on  computers,  continued  with  improvements  in  data 
access,  and  more  recently  generated  technologies  that  allow  users  to  navigate  through  their  data  in  real 
time.  Data  mining  takes  this  evolutionary  process  beyond  retrospective  data  access  and  navigation  to 
prospective  and  proactive  information  delivery.  Data  mining  is  ready  for  application  in  the  various 
businesses  because  it  is  supported  by  three  main  technologies  that  are  now  sufficiently  mature: 

•  Massive  data  collection 

•  Powerful  multiprocessor  computers 

•  Data  mining  algorithms 

The  core  components  of  data  mining  technology  have  been  under  development,  in  research  areas  such 
as  statistics,  artificial  intelligence,  and  machine  learning.  Today,  the  maturity  of  these  techniques,  coupled 
with  high-performance  relational  database  engines  and  broad  data  integration  efforts,  make  these 
technologies  practical  for  current  data  warehouse  environments.  Finally,  data  mining  technology  can 
generate  new  business  opportunities  by  providing  the  following  two  main  capabilities: 

•  Automated  prediction  of  trends  and  behaviors:  data  mining  automates  the  process  of  finding 
predictive  information  in  large  databases. 

•  Automated  discovery  of  previously  unknown  patterns:  data  mining  tools  sweep  through 
databases  and  identify  previously  hidden  patterns  in  one  step. 

In  the  software  and  hardware  point  of  view,  data  mining  techniques  can  yield  the  benefits  of  automation 
on  existing  platforms,  and  can  be  implemented  on  new  systems  as  existing  platforms  are  upgraded  and 
new  products  developed.  When  data  mining  tools  are  implemented  on  high  performance  parallel 
processing  systems,  they  can  analyze  massive  databases  in  minutes.  Faster  processing  means  that 
users  can  automatically  experiment  with  more  models  to  understand  complex  data.  High  speed  makes  it 
practical  for  users  to  analyze  huge  quantities  of  data.  Larger  databases,  in  turn,  yield  improved 
predictions. 

7.3.2  Data  Mining,  Machine  Learning,  and  Statistics 

Data  mining  takes  advantage  of  advances  in  the  fields  of  artificial  intelligence  (Al)  and  statistics.  Both 
disciplines  have  been  working  on  problems  of  pattern  recognition  and  classification.  Both  communities 
have  made  great  contributions  to  the  understanding  and  application  of  neural  nets  and  decision  trees. 

Data  mining  does  not  replace  traditional  statistical  techniques.  Rather,  it  is  an  extension  of  statistical 
methods  that  is  in  part  the  result  of  a  major  change  in  the  statistics  community.  The  development  of  most 
statistical  techniques  was,  until  recently,  based  on  elegant  theory  and  analytical  methods  that  worked 
quite  well  on  the  modest  amounts  of  data  being  analyzed.  The  increased  power  of  computers  and  their 
lower  cost,  coupled  with  the  need  to  analyze  enormous  data  sets  with  millions  of  rows,  have  allowed  the 
development  of  new  techniques  based  on  a  brute-force  exploration  of  possible  solutions  [4], [5], [6]. 
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New  techniques  include  relatively  recent  algorithms  like  decision  trees,  and  new  approaches  to  older 
algorithms  such  as  discriminant  analysis.  By  virtue  of  bringing  to  bear  the  increased  computer  power  on 
the  huge  volumes  of  available  data,  these  techniques  can  approximate  almost  any  functional  form  or 
interaction  on  their  own.  Traditional  statistical  techniques  rely  on  the  modeler  to  specify  the  functional 
form  and  interactions. 

The  key  point  is  that  data  mining  is  the  application  of  these  and  other  Al  and  statistical  techniques  to 
common  business  problems  in  a  fashion  that  makes  these  techniques  available  to  the  skilled  knowledge 
worker  as  well  as  the  trained  statistics  professional.  Data  mining  is  a  tool  for  increasing  the  productivity  of 
people  trying  to  build  predictive  models. 

7.3.3  Data  Mining  Applications 

Data  mining  is  increasingly  popular  because  of  the  substantial  contribution  it  can  make.  It  can  be  used  to 
control  costs  as  well  as  contribute  to  performance  increases. 

Many  organizations  are  using  data  mining  to  help  manage  all  phases  of  the  product  or  customer  life  cycle, 
including  acquiring  new  products  or  customers,  increasing  revenue  from  existing  products  or  customers, 
and  maintaining  good  products  or  customers.  By  determining  characteristics  of  products  or  customers,  an 
organization  can  apply  specific  strategies  to  the  groups  with  similar  characteristics. 

Data  mining  also  offers  value  across  a  broad  spectrum  of  organizations.  Telecommunications  and  credit 
card  companies  are  two  of  the  leaders  in  applying  data  mining  to  detect  fraudulent  use  of  their  services. 
Insurance  companies  and  stock  exchanges  are  also  interested  in  applying  this  technology  to  reduce  fraud. 
Medical  applications  are  another  fruitful  area:  data  mining  can  be  used  to  predict  the  effectiveness  of 
surgical  procedures,  medical  tests  or  medications.  Companies  active  in  the  financial  markets  use  data 
mining  to  determine  market  and  industry  characteristics  as  well  as  to  predict  individual  company  and 
stock  performance.  Retailers  are  making  more  use  of  data  mining  to  decide  which  products  to  stock  in 
particular  stores  (and  even  how  to  place  them  within  a  store),  as  well  as  to  assess  the  effectiveness  of 
promotions  and  coupons.  Pharmaceutical  firms  are  mining  large  databases  of  chemical  compounds  and 
of  genetic  material  to  discover  substances  that  might  be  candidates  for  development  as  agents  for  the 
treatments  of  disease. 

7.3.4  Data  Mining  Models  and  Algorithms 

Most  of  the  models  and  algorithms  discussed  in  this  section  can  be  thought  of  as  generalizations  of  the 
standard  workhouse  of  modeling,  the  linear  regression  model.  Much  effort  has  been  expended  in  the 
statistics,  computer  science,  artificial  intelligence,  and  engineering  communities  to  overcome  the 
limitations  of  this  basic  model.  The  common  characteristic  of  many  of  the  newer  technologies  is  that  the 
pattern-finding  mechanism  is  data-driven.  That  is,  the  relationships  are  found  inductively  by  the  software 
itself  based  on  the  existing  data. 

The  most  important  thing  to  remember  is  that  no  one  model  or  algorithm  can  or  should  be  used 
exclusively.  For  any  given  problem,  the  nature  of  the  data  itself  will  affect  the  choice  of  models  and 
algorithms.  There  is  no  best  model  or  algorithm.  Consequently,  it  is  necessary  to  require  a  variety  of  tools 
and  technologies  in  order  to  find  the  best  possible  model. 

7.3.4. 1  Neural  Networks 

Neural  networks  are  of  particular  interest  because  they  offer  a  means  of  efficiently  modeling  large  and 
complex  problems  in  which  there  may  be  hundreds  of  predictor  variables  that  have  many  interactions. 
Neural  nets  may  be  used  in  classification  problems,  where  the  output  is  a  categorical  variable,  or  for 
regressions,  where  the  output  variable  is  continuous. 
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Figure  7.3.1  A  Neural  Network  with  One  Hidden  Layer 

A  neural  network  starts  with  an  input  layer,  where  each  node  corresponds  to  a  predictor  variable.  Each 
input  node  is  connected  to  every  node  in  the  hidden  layer.  The  nodes  in  the  hidden  layer  may  be 
connected  to  nodes  in  another  hidden  layer,  or  to  an  output  layer.  The  output  layer  consists  of  one  or 
more  response  variables. 

7. 3. 4. 2  Decision  Trees 

Decision  trees  are  a  way  of  representing  a  series  of  rules  that  lead  to  a  class  or  value.  Depending  on  the 
algorithm,  each  tree  node  may  have  two  or  more  branches.  Each  branch  will  lead  either  to  another 
decision  node  or  to  the  bottom  of  the  tree,  called  a  leaf  node. 

By  navigating  the  decision  tree,  a  value  or  class  can  be  assigned  to  a  case  by  deciding  which  branch  to 
take,  starting  at  the  root  node  and  moving  to  each  subsequent  node  until  a  leaf  node  is  reached.  Each 
node  uses  the  data  from  the  case  to  choose  the  appropriate  branch. 

Decision  tree  models  are  commonly  used  in  data  mining  to  examine  the  data  and  induce  the  tree  and  its 
rules  that  will  be  used  to  make  predictions.  A  number  of  different  algorithms  may  be  used  for  building 
decision  trees  including  CHAID  (Chi-squared  Automatic  Interaction  Detection),  CART  (Classification  and 
Regression  Trees),  Quest,  and  C5.0. 

Decision  trees  which  are  used  to  predict  categorical  variables  are  called  classification  trees  because  they 
place  instances  in  categories  or  classes.  Decision  trees  used  to  predict  continuous  variables  are  called 
regression  trees.  Decision  trees  make  few  passes  through  the  data  (no  more  than  one  pass  for  each  level 
of  the  tree)  and  they  work  well  with  many  predictor  variables.  As  a  consequence,  models  can  be  built  very 
quickly,  making  them  suitable  for  large  data  sets. 

Decision  trees  handle  non-numeric  data  very  well.  This  ability  to  accept  categorical  data  minimizes  the 
amount  of  data  transformations  and  the  explosion  of  predictor  variables  inherent  in  neural  nets. 

Some  classification  trees  were  designed  for  and  therefore  work  best  when  the  predictor  variables  are  also 
categorical.  Continuous  predictors  can  frequently  be  used  even  in  these  cases  by  converting  the 
continuous  variable  to  a  set  of  ranges.  Some  decision  trees  do  not  support  continuous  response  variables, 
in  which  case  the  response  variables  in  the  training  set  must  also  be  ranged  to  output  classes. 

7. 3. 4. 3  K-Nearest  Neighbors 

When  trying  to  solve  new  problems,  some  algorithms  often  look  at  solutions  to  similar  problems  that  they 
have  previously  solved.  K-nearest  neighbor  (k-NN)  is  a  classification  technique  that  uses  a  version  of  this 
same  method.  It  decides  in  which  class  to  place  a  new  case  by  examining  some  number  —  the  “k"  in  k- 
nearest  neighbor —  of  the  most  similar  cases  or  neighbors.  It  counts  the  number  of  cases  for  each  class, 
and  assigns  the  new  case  to  the  same  class  to  which  most  of  its  neighbors  belong. 


76 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3) 


The  first  thing  to  be  done  to  apply  k-NN  is  to  find  a  measure  of  the  distance  between  attributes  in  the  data 
and  then  calculate  it.  While  this  is  easy  for  numeric  data,  categorical  variables  need  special  handling. 
Once  the  distance  between  cases  is  calculated,  then,  select  the  set  of  already  classified  cases  to  use  as 
the  basis  for  classifying  new  cases,  decide  how  large  a  neighborhood  in  which  to  do  the  comparisons, 
and  also  decide  how  to  count  the  neighbors  themselves. 

K-NN  puts  a  large  computational  load  on  the  computer  because  the  calculation  time  increases  as  the 
factorial  of  the  total  number  of  points.  While  it  s  a  rapid  process  to  apply  a  decision  tree  or  neural  net  to  a 
new  case,  k-NN  requires  that  a  new  calculation  be  made  for  each  new  case.  To  speed  up  k-NN, 
frequently  all  the  data  is  kept  in  memory.  Memory-based  reasoning  usually  refers  to  a  k-NN  classifier  kept 
in  memory. 

K-NN  models  are  very  easy  to  understand  when  there  are  few  predictor  variables.  They  are  also  useful 
for  building  models  that  involve  non-standard  data  types,  such  as  text.  The  only  requirement  for  being 
able  to  include  a  data  type  is  the  existence  of  an  appropriate  metric. 

7. 3. 4. 4  K-Means  Clustering 

A  non-hierarchical  approach  to  forming  good  clusters  is  to  specify  a  desired  number  of  clusters,  say,  k, 
then  assign  each  case  to  one  of  k  clusters  so  as  to  minimize  a  measure  of  dispersion  within  the  clusters. 
A  very  common  measure  is  the  sum  of  distances  or  sum  of  squared  Euclidean  distances  from  the  mean 
of  each  cluster.  The  problem  can  be  set  up  as  an  integer  programming  problem  but  because  solving 
integer  programs  with  a  large  number  of  variables  is  time  consuming,  clusters  are  often  computed  using  a 
fast,  heuristic  method  that  generally  produces  good  solutions. 

The  k-means  algorithm  starts  with  an  initial  partition  of  the  cases  into  k  clusters.  Subsequent  steps  modify 
the  partition  to  reduce  the  sum  of  the  distances  for  each  case  from  the  mean  of  the  cluster  to  which  the 
case  belongs.  The  modification  consists  of  allocating  each  case  to  the  nearest  of  the  k  means  of  the 
previous  partition.  This  leads  to  a  new  partition  for  which  the  sum  of  distances  is  strictly  smaller  than 
before.  The  improvement  step  is  repeated  until  the  improvement  is  very  small.  The  method  is  very  fast. 
There  is  a  possibility  that  the  improvement  step  leads  to  fewer  than  k  partitions.  In  this  situation  one  of  the 
partitions  (generally  the  one  with  the  largest  sum  of  distances  from  the  mean)  is  divided  into  two  or  more 
parts  to  reach  the  required  number  of  k  partitions.  The  algorithm  can  be  rerun  with  different  randomly 
generated  starting  partitions  to  reduce  the  chances  of  the  heuristic  producing  a  poor  solution.  Generally 
the  number  of  true  clusters  in  the  data  is  not  known.  Therefore,  it  is  a  good  idea  to  run  the  algorithm  with 
different  values  for  k  that  are  near  the  number  of  clusters  one  expects  from  the  data  to  see  how  the  sum 
of  distances  reduces  with  increasing  values  of  k. 

7. 3. 4. 5  Discriminant  Analysis 

Discriminant  analysis  is  the  oldest  mathematical  classification  technique,  having  been  first  published  by  R. 
A.  Fisher  in  1936  to  classify  the  famous  Iris  botanical  data  into  three  species.  It  finds  hyper  planes  (e.g., 
lines  in  two  dimensions,  planes  in  three,  etc.)  that  separate  the  classes.  The  resultant  model  is  very  easy 
to  interpret  because  all  the  user  has  to  do  is  determine  on  which  side  of  the  line  (or  hyper-plane)  a  point 
falls.  Training  is  simple  and  scalable.  The  technique  is  very  sensitive  to  patterns  in  the  data. 

Even  the  boundaries  that  separate  the  classes  are  all  linear  forms  (such  as  lines  or  planes),  recent 
versions  of  discriminant  analysis  address  some  of  these  problems  by  allowing  the  boundaries  to  be 
quadratic  as  well  as  linear,  which  significantly  increases  the  sensitivity  in  certain  cases.  There  are  also 
techniques  that  allow  the  normality  assumption  to  be  replaced  with  an  estimate  of  the  real  distribution. 
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7.3.5  Data  Mining  Classification 

7.3.5. 1  Classification  (Supervised  Learning) 

Classification  in  data  mining  is  a  supervised  learning.  Supervised  learning  processes  are  as  follows;  first, 
prepare  set  of  samples  which  has  correct  class  for  the  each  data,  and  divide  samples  into  two  sets,  one  is 
training  dataset  and  the  other  is  test  dataset,  second,  create  a  model  by  learning  the  selected  algorithm 
on  the  training  data,  third,  validate  and  evaluate  the  created  model  with  test  dataset  and  model  evaluating 
methods,  and  finally,  identify  a  class  for  the  new  incoming  data. 

The  aim  of  classification  problems  is  to  identify  the  characteristics  that  indicate  the  group  to  which  each 
case  belongs.  This  pattern  can  be  used  both  to  understand  the  existing  data  and  to  predict  how  new 
instances  will  behave. 

Data  mining  creates  classification  models  by  examining  already  classified  data  (cases)  and  inductively 
finding  a  predictive  pattern.  These  existing  cases  may  come  from  an  historical  database.  Also,  they  may 
come  from  an  experiment  in  which  a  sample  of  the  entire  database  is  tested  in  the  real  world  and  the 
results  used  to  create  a  classifier. 

7. 3. 5.1 .1  Classification  Algorithms 

Among  many  classification  algorithms,  following  algorithms,  linear  regression  of  an  indicator  matrix,  linear 
discriminant  analysis,  and  quadratic  discriminant  analysis,  are  applied  in  this  study. 

7. 3. 5.1 .1 .1  Linear  Regression  of  an  Indicator  Matrix 

In  linear  regression  of  an  indicator  matrix  algorithm,  each  of  the  response  categories  are  coded  via  an 
indicator  variable.  This  if  there  are  g  -  K  classes,  there  will  be  K  such  indicators  Yk,  k  =  7,  .  K,  with  Yk  = 

1  if  G  =  k  else  0.  These  are  collected  together  in  a  vector  Y  =  (Y1f  Y2,  . ,  Yk ),  and  the  N  training 

instances  of  these  form  an  N  X  K  indicator  response  matrix  Y.  Y  is  a  matrix  of  0's  and  I’s,  with  each  row 
having  a  single  1 .  Following  is  a  brief  process  for  linear  regression  of  an  indicator  matrix  method. 

Creating  Y Matrix,  Y  =  (Yh  Y2r  . ,  Yk) 

Linear  Fit:  Y  =  X(XT X)~]  XrY 

Coefficient  Matrix:  B  ~  (XT X)~l  XrY 
Compute  the  Fitted  Output:  f(x)  =  [(l,x)i?]r 

Classification  with  identifying  the  largest  component:  G(x)  =  arg  maxA  „  fk  (x) 


7.3. 5.1 .1 .2  Linear  Discriminant  Analysis 


Decision  theory  for  classification  shows  the  necessity  of  the  class  posteriors  Pr(G|X)  for  optimal 
classification.  Suppose  fk(x)  is  the  class-conditional  density  of  X  in  class  G  =  k,  and  let  nk  be  the  prior 

probability  of  class  k,  with  nk  —  1 .  A  simple  application  of  Bayes  theorem  gives, 


Pr(C  =  k\X  =  x)  = 


/*  (4 


\n, 


Z/.i //(*)*/ 


It  can  be  shown  that  in  terms  of  ability  to  classify,  having  the  fk(x)  is  almost  equivalent  to  having  the 
quantity  Pr(G=k\X-x). 

Many  techniques  are  based  on  models  for  the  class  densities; 


linear  and  quadratic  discriminant  analysis  use  Gaussian  densities; 

more  flexible  mixtures  of  Gaussians  allow  for  nonlinear  decision  boundaries; 
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general  nonparametric  density  estimates  for  each  class  density  allow  the  most  flexibility; 

Naive  Bayes  models  are  a  variant  of  the  previous  case,  and  assume  that  each  of  the  class  densities  are 
products  of  marginal  densities;  that  is,  they  assume  that  the  inputs  are  conditionally  independent  in  each 
class. 


Suppose  that  each  class  density  can  be  modeled  as  multivariate  Gaussian,  shown  as  following  equation; 


/*M= 


i 


faY'% 


1 1  /  2 


“(*-/**  f  %il  (x-Mk ) 

e  - 


Linear  discriminant  analysis  (LDA)  arises  in  the  special  case  when  it  is  assumed  that  the  classes  have  a 
common  covariance  matrix  XA.  -  X  \/k  . 


Following  shows  brief  process  of  linear  discriminant  analysis  method: 
Assume  Gaussian  distribution 

Assume  all  classes  have  a  common  covariance  matrix 

S*  =Z  V* 

Linear  Discriminant  Functions 

d'k(x)  =  xTl-'/jk -X-MTkZ-'nk  +log^*. 

Estimate  parameters  of  the  Gaussian  distributions  using  the  training  dataset 
ft f  -  N k  /N ,  where  Nk  is  the  number  of  class  k  observations; 

A  =  X,  W**  : 

s  -  XX  X.  *  -  A  to,  A  )r/(^  -  *) 

G(x)  =  arg  ma xA.  Sk  (x) 


7.3.5. 1 .1 .3  Quadratic  Discriminant  Analysis 

In  each  class  density,  modeled  as  multivariate  Gaussian,  if  the  XA  are  not  assumed  to  be  equal,  then  the 

quadratic  discriminant  functions  can  be  generated.  With  this  function,  quadratic  discriminant  analysis  can 
be  conducted. 

Following  shows  brief  process  of  quadratic  discriminant  analysis  method. 

Assume  Gaussian  distribution 
Each  class  has  own  covariance  matrix 

A,  )(*,- A,  )rM 

Quadratic  Discriminant  Functions 

A  (*)  =  "  *og|A  I  -  y  (*  -  Ml  V  (x  -ftk)  +  log  nk 

Estimate  parameters  of  the  Gaussian  distributions  using  the  training  dataset 
n k  —  Nk  / N ,  where,  Nk  is  the  number  of  class  k  observations; 

A  =Xie,WA'* ; 

G(x)  =  arg  max,  Sk  (x) 
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7.3.6  Validation  and  Dimension  Reduction  Techniques  in  Data  Mining  Model 
7.3.6. 1  Cross  Validation 


To  evaluate  the  classification  algorithms,  cross  validation  method  can  be  introduced  since  it  is  the 
simplest  and  most  widely  used  method  for  estimating  prediction  error. 

With  this  method,  the  extra-sample  error,  Err  =  £ [/.(}',  f(X ))],  can  be  directly  estimated. 

Since  sample  data  (E0947  SECREPS)  are  scarce,  K-fold  cross  validation  is  used.  This  uses  part  of  the 
available  data  to  fit  the  model,  and  a  different  part  to  test  it.  In  this  study,  sample  data  is  split  into  5 
roughly  equal-sized  parts.  This  5-fold  cross  validation  scenario  looks  like  following  figure: 


Set  1  Set  2  Set  3 


Set  k 


Test 


Titiin 


Tiaiii]  ■ 


■  Tiain 


>4 


Train  Test  Train . Train 


| Train  Train 

Test 

|  Train  | 

|  Train  Tiain 

|  Train 

Test  | 

Exp.  1 
Exp.  2 
Exp.  3 

Exp.  k 


Figure  7.3.2  Cross  Validation 


7. 3. 6. 2  Principal  Component  Analysis  (Dimension  Reduction) 

By  retaining  a  subset  of  the  predictors  and  discarding  the  rest,  subset  selection  produces  a  model  that  is 
interpretable  and  has  possibly  lower  prediction  error  than  the  full  model.  In  this  study,  principal 
component  (or  Karhunen-Loeve)  analysis  is  used  as  a  dimension  reduction  method. 

The  sample  covariance  matrix  is  given  by  S  -  XT X / N  .  And  the  eigen  decomposition  of  XT X  is 

given  by:  XT X  —  VDV7  .  Matrix  D  \s  a  pxp  diagonal  matrix  in  which  the  diagonal  element 

D(i  =  di  >  0.  We  can  always  rearrange  D  such  that  dt  >  d /  if  i  <  j  .  The  column  vector  of  V  ,  i.e.  the 

eigenvector  vj}  is  called  the  principal  component  direction  of  X  .  X  can  be  transformed  into  a  new 

variable  matrix  Z  -  XV ,  which  lies  in  the  space  spanned  by  eigenvectors  vj 's.  The  ith  column  of  Z, 

ti,  d 

Zj  =Xvt,  is  called  the  /  'principle  component  of  X .  It’s  easy  to  show  Var(zt)  =  .  Since  d/s  are 

sorted  as  decreasing  sequence,  Var(z-)  is  also  a  decreasing  sequence. 

From  the  above  analysis,  we  can  see  that  the  first  principle  component  direction  v,  is  a  direction  in  the 
original  space  along  which  the  sample  has  the  most  variation.  On  the  contrary,  the  last  component  v  is 

the  direction  along  which  the  sample  has  the  least  variation.  So  if  we  want  to  reduce  the  number  of 
predictors  from  pio  p-k,  the  predictors  that  we  need  in  the  new  space  are  the  first  p-k  principle 

components 2|}22,...,2  A  . 
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7.3.7  Applying  Data  Mining  to  IDGE  Study 

Data  Mining  can  be  applied  as  an  alternative  decision  support  tool  in  IDGE  architecture.  This  will  support 
the  maintenance  strategies,  for  example,  applying  different  maintenance  rules  based  on  the  mission/risk 
for  a  part  or  an  item  (e.g.  SECREPS).  This  will  also  support  the  automated  O.A.  processes  in  IDGE 
architecture,  for  example,  applying  different  business  rules  (e.g.  inventory  fulfillment)  based  on  the  fill-up 
strategy  for  a  part  or  an  item. 


Figure  7.3.3  Decision  Support  Systems  in  IDGE  Architecture 


7.3.7. 1  Data  Mining  Concepts  as  a  Supplement  for  the  Quadrant  Model 

The  Quadrant  Model  is  a  currently  proposed  decision  support  system  for  the  ILC  (Integrated  Logistics 
Capability).  However,  further  refinement  and  specification  rules  are  required  to  the  Quadrant  Model. 

There  are  several  known  drawbacks  in  current  Quadrant  Model.  First,  it  was  found  that  in  many  cases  the 
attributes  for  calculating  mission  or  risk  value  for  a  part  or  an  item  are  inappropriate,  and  in  some  cases 
attributes  does  not  exist  at  all.  Second,  parts  or  items  lying  in  the  near  the  decision  dividers  or  extremes 
of  any  Quadrant  is  entirely  controlled  by  the  same  business  rules  established  for  the  segment  of 
Quadrant.  With  respect  to  the  above  known  drawbacks  of  Quadrant  Model,  Data  Mining  technique  is 
expected  to  offer  following  possible  advantages  and  solutions. 

First,  data  mining  can  consider  all  related  attributes  of  the  part  or  item.  This  aspect  will  help  make  more 
reliable  and  accurate  decisions  to  classify  the  part  or  item. 
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Figure  7.3.4  Considering  All  Related  Attributes  of  a  Part  or  an  Item 
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Second,  once  predictor  engine  for  the  classification  algorithm  is  developed,  then  the  processes  of 
classifying  the  parts  or  items  are  automatically  executed. 

Third,  classification  algorithms  can  be  easily  and  quickly  updated  when  input  information  for  the  algorithm 
is  updated. 

Fourth,  unlike  quadrant  model,  it  is  not  necessary  to  modify  or  change  the  original  value  into  modified 
value  and  weighed  value.  Based  on  classification  algorithms,  categorical  value  (alphabetic  value)  also 
can  be  used  directly  in  data  mining  approach. 
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Figure  7.3.5  Comparing  the  Input  Information  in  Quadrant  Model  and  Data  Mining 

Approach 

These  various  advantages  will  guarantee  data  mining  classification  approach  to  follow  two  most  important 
objectives  of  the  decision  support  systems,  Timeliness’  and  ‘Real  time’,  in  IDGE  study. 

Data  mining  brings  in  greater  granularity  in  the  classification  and  appropriate  decision  rules  and  strategies 
for  the  specific  segments  can  be  applied  into  maintenance  and  O.A.  processes  for  the  parts  or  items. 
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7.4  Appendix  4  -  Sensor  Fusion  and  Fault  Diagnosis 

7.4.1  Model  Updates  and  Current  State  of  Technology 

The  model  has  evolved  since  its  original  exposition  to  the  data  fusion  community.  Steinberg  and 
Bowman  [83],  for  example,  have  recommended  the  inclusion  of  a  new  Level  zero  processing  to  account 
for  processing  such  as  pre-detection  fusion  and  coherent  signal  processing  of  multi-sensor  data.  In 
addition,  they  suggest  a  re-naming  and  re-interpretation  of  the  Level  2  and  Level  3  processes  to  focus  on 
understanding  the  external  world  environment  (rather  than  a  military-oriented  situation  and  threat  focus). 
C.  Morefield  [74]  has  suggested  that  the  distinction  between  Level  2  and  Level  3  is  artificial,  and  that 
these  processes  should  be  considered  as  a  single  process.  Bowman  has  suggested  that  the  JDL  model 
can  be  detrimental  to  communications  if  systems  engineers  focus  on  the  model  rather  than  a  systematic 
architecture  analysis  and  decomposition  approach.  Despite  these  remarks  the  JDL  model  offers  more 
benefits  than  disadvantages,  There  are  several  modifications  to  the  original  JDL  model  that  are  under 
development.  Table  5.2  provides  an  augmented  listing  of  the  processes  envisioned  in  an  updated  model. 


Table  7.4.1  Summary  of  Current  State  of  Multisensor  Data  Fusion 

JDL  Process 

Current  Practices 

Limitations  &  Challenges 

Level  1 :  Object 
refinement 

■  Sensor  preprocessing  using  standard 
signal  and  image  processing  methods 

■  Explicit  separation  of  correlation  and 
estimation  problem 

■  Multiple  target  tracking  using  MHT  [11], 
JPDA  [6],  etc. 

■  Use  of  ad  hoc  maneuver  models 

■  Object  ID  dominated  by  feature  based 
methods  [30] 

■  Pattern  recognition  using  ANN  [57] 

■  Emerging  guidelines  for  selection  of 
correlation  algorithms  [83],  [69] 

■  Promising  work  by  Poore  [77]  ,  Mahler 
[74],  Barlow,  et  a!  [5] 

■  Dense  target  environments 

■  Rapidly  maneuvering  targets 

■  Complex  signal  propagation 

■  Co-dependent  sensor 

observations 

■  Background  clutter 

■  Context-based  reasoning 

■  Integration  of  identity  and 
kinematic  data 

■  Lack  of  available  ANN  training 
data  (for  target  identification)  [57] 

■  No  true  fusion  of  image  and  non¬ 
image  data  (at  the  data  level) 

Level  2:  Situation 
Refinement 

■  Numerous  prototype  systems  [50] 

■  Dominance  of  rule-based  KBS 

■  Variations  include  blackboard 

systems[68],  logical  templating  [42],  and 
case-based  reasoning  [189] 

■  Emerging  use  of  fuzzy-logic  [78]  and 
agent-based  systems  [81] 

■  Very  limited  operational  systems 

■  No  experience  in  scaling  up 
prototypes  to  operational  systems 

■  Very  limited  cognitive  models  [53] 

■  Perfunctory  test  and  evaluation 
against  toy  problems  [50] 

■  No  proven  technique  for 

knowledge  engineering  [51] 

Level  3:  Threat 
Refinement 

■  Same  as  Level  2  Processing 

■  Limited  advisory  status 

■  Limited  deployment  experience 

■  Dominated  by  ad  hoc  methods 

■  Doctrine-specific,  fragile 

implementations 

■  Same  as  level  2 

■  Difficulty  to  quantify  intent  [49] 

■  Models  require  established 

enemy  doctrine 

■  Difficult  to  model  rapidly  evolving 
situations 

Level  4:  Process 
Refinement 

, 

■  Robust  methods  for  single-sensor 

systems 

■  Formulations  based  on  operations 

research  [51] 

■  Limited  context-based  reasoning 

■  Focus  on  measures  of  performance 

(MOP)  versus  measures  of  effectiveness 

■  Difficult  to  incorporate  mission 

constraints 

■  Scaling  problem  when  many 

sensors  (10N)  and  adaptive  systems 
[52] 

■  Difficult  to  optimally  use  non- 

commensurate  sensors 
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(MOE)  [91] 

■  Very  difficult  to  link  human 
information  needs  to  sensor  control 
[37] 

Human  Computer 
Interface  (HCI) 

•  HCI  dominated  by  the  technology  of  the 
week 

■  Focus  on  ergonomic  versus  cognitive- 
based  design 

■  Numerous  graphics-based  displays  and 
systems  [3],  [82] 

■  Advanced,  3-D  full  immersion  HCI 
available  [89]  and  haptic  interfaces  [28], 
[56] 

■  Very  little  research  has  been 
performed  to  understand  how  human 
analysts’  process  data  and  make 
accurate  inferences. 

■  Creative  HCI  is  needed  to  adapt 
to  individual  users  and  to  provide 
mitigation  of  known  cognitive  biases 
and  illusions  [53],  [76] 

Data  Base 

Management 

■  Extensive  use  of  4th  and  5m  generation 

COTS  DBMS 

■  DBMS  individually  optimized  for  text, 
signal  data,  imagery,  or  symbolic 
information  (but  not  the  intersection  of  any 
two) 

■  DBMS  requires  extensive  tailoring  for 
individual  data  fusion  systems 

■  Need  a  generalized  DBMS 
capability  for  text,  signal  data, 
images,  and  symbolic  information 

■  Need  a  software  solution  to  multi¬ 
level  security 

7.4.2  Implementation  of  Data  Fusion  Systems 

Methods  for  fusing  multi-sensor  data  are  drawn  from  a  wide  variety  of  disciplines  including  signal 
processing,  image  processing,  statistics,  pattern  recognition,  and  automated  reasoning.  Many  of  these 
techniques  have  an  extensive  history,  ranging  from  Bayesian  inference  (first  published  in  1763)  to  fuzzy 
logic  (originating  in  the  1920s)  to  neural  nets  (developed  in  the  1940s). 

7.4.2. 1  Aspects  of  Implementation 

Some  issues  related  to  the  implementation  of  data  fusion  systems  are  addressed  in  this  section.  While 
each  data  fusion  system  constitutes  a  separate  problem  in  systems  engineering,  there  are  some  general 
remarks  that  can  be  made  about  requirement  analysis,  sensor  selection,  architecture  selection,  algorithm 
selection,  software  implementation,  and  test  and  evaluation.  These  are  summarized  below. 

Requirement  Analysis  -  The  initial  step  for  the  implementation  of  any  complex  system  is  to  perform  a 
requirement  analysis.  In  a  typical  structured  system  development  approach,  formal  analyses  are 
performed,  culminating  in  a  requirement  review  and  associated  documentation.  This  approach  is  also 
recommended  for  the  development  of  data  fusion  systems.  It  should  be  remembered  that  data  fusion  is  a 
derived  requirement.  Strictly  speaking  there  is  no  such  thing  as  a  data  fusion  system.  Instead  there  are 
systems  designed  to  address  specific  applications  or  to  achieve  specified  missions.  These  systems  may 
utilize  data  fusion  algorithms  to  achieve  the  application  or  mission  goals.  Under  this  perspective,  the 
system  designer  must  understand  what  the  mission  goals  or  application  goals  are.  What  targets  or 
entities  must  be  detected,  characterized,  or  identified?  Who  are  the  intended  users  of  the  system  and 
what  decisions  must  these  users  make  (to  achieve  a  mission)?  This  approach  focuses  on  the  end-user  of 
the  data  fusion  system  rather  than  on  the  sensors.  All  too  often,  system  designers  treat  a  data  fusion 
system  as  a  bucket  used  to  collect  or  process  the  sensor  data,  rather  than  a  system  to  support  an  end- 
user.  The  requirement  analysis  must  consider  the  effects  of  the  observing  environment,  the  end-user,  the 
platform  (on  which  the  sensors  are  located),  communication  constraints,  and  computing  limitations.  Key 
issues  include  the  observing  and  decision  timeline  and  required  level  of  specificity  and  accuracy.  An 
excellent  discussion  of  requirement  analysis  for  data  fusion  system  is  available  in  Waltz  and  Llinas  [91]. 

Sensor  selection  and  analysis  -  Often,  the  sensors  associated  with  a  data  fusion  system  are  specified  a 
priori.  This  is  frequently  the  case  for  existing  platforms  such  as  aircraft  or  ships  for  which  a  data  fusion 
system  must  be  developed.  However,  even  if  the  sensors  are  specified  a  priori,  it  is  necessary  to  perform 


84 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3) 


an  analysis  of  the  sensors.  In  general,  there  is  no  single  sensor  that  can  detect,  locate,  characterize,  and 
identify  the  targets  of  interest  under  all  circumstances  (i.e.,  there  is  no  perfect  sensor).  Indeed,  the  lack 
of  a  perfect  sensor  is  one  of  the  motivations  for  developing  a  data  fusion  system.  A  key  component  of  the 
system  development  process  is  to  understand  how  the  sensors  perform,  both  individually  and  in  concert, 
to  contribute  to  inferences  sought  by  the  data  fusion  system.  Sensor  selection  and  analysis  must 
determine  what  can  be  observed,  and  how  these  observable  quantities  relate  to  the  targets  or  inferences 
of  interest.  Steinberg  (reference)  provides  an  excellent  example  of  this  type  of  analysis  for  a  tactical 
aircraft.  The  system  designer  should  develop  or  utilize  high  fidelity  models  that  predict  how  sensors  will 
perform  in  realistic  environments.  These  models  should  include  the  effects  of  the  target,  the  signal 
propagation  environment,  the  location  of  the  sensor  antenna  on  an  observing  platform,  and  the  internal 
sensor  processing.  In  addition,  real  data  should  be  collected  and  analyzed.  It  is  important  to  understand 
and  accurately  model  sensor  performance.  These  estimates  should  be  used  to  help  weight  the  sensor 
data  in  the  data  fusion  process.  If  the  performance  estimates  are  not  accurate,  then  it  can  corrupt  all  of 
the  down-stream  fusion  processing. 

Architecture  selection  -  Modern  data  fusion  systems  often  involve  distributed  sensors  and  processing 
systems.  Examples  include  systems  on-board  a  single  platform  (e.g.,  an  aircraft)  linked  via  a  computer 
network  such  as  Ethernet  and  unattended  ground  sensor  systems  in  which  multiple  sensors  are  linked 
using  wireless  communications.  In  these  systems  processing  is  performed  both  at  the  sensors  and  at  a 
centralized  processing  computer.  A  basic  question  for  the  system  designer  is  to  determine  where  in  the 
processing  flow  should  the  fusion  actually  be  performed?  Conceptually,  there  are  three  basic  types  of 
architectures  for  data  fusion2;  (1)  centralized  fusion,  (2)  distributed  fusion,  and  (3)  hybrid  fusion.  The 
centralized  fusion  architecture  involves  passing  raw  sensor  data  (e.g.,  time  series,  images,  vectors)  from 
the  sensors  to  a  central  fusion  processing  function.  In  this  approach  the  raw  sensor  data  must  be 
associated,  correlated,  and  fused.  The  centralized  fusion  architecture  is  potentially  the  most  accurate 
approach  for  fusion  of  information  (since  the  raw  data  are  available  for  processing).  However,  the 
centralized  approach  may  require  significant  communication  resources  to  send  the  data  from  the  sensors 
to  the  centralized  fusion  process.  In  addition,  the  centralized  approach  may  be  difficult  to  actually 
achieve  for  non-commensurate  sensors. 

In  the  distributed  fusion  approach,  sensor  data  are  processed  to  result  in  state  vector  estimates  for 
observed  targets.  These  estimates  may  contain  estimates  of  the  target's  position,  velocity,  attributes,  and 
identities.  In  the  distributed  fusion  architecture  the  processing  is  effectively  distributed  among  the 
sensors  and  other  fusion  processing  computers.  Distributed  fusion  reduces  the  amount  of  information 
that  must  be  communicated  between  the  sensors  and  the  fusion  processor  (i.e.,  instead  of  raw  data  sent 
from  the  sensors  to  the  fusion  processor,  only  state  vectors  or  feature  vectors  are  sent  from  the  sensors 
to  the  fusion  processor).  In  addition,  distributed  fusion  is  convenient  for  processing  information  from 
diverse  types  of  sensors.  A  potential  problem  with  distributed  fusion  is  a  loss  of  accuracy  because  the 
raw  data  are  not  available  for  fusion. 

Finally,  hybrid  fusion  architectures  combine  both  a  centralized  approach  and  a  distributed  approach.  This 
allows  the  system  to  limit  communication  resource  utilization  (using  the  distributed  mode  of  operation),  or 
to  improve  accuracy  by  processing  the  raw  sensor  data.  Hybrid  fusion  provides  the  most  flexible  type  of 
architecture  at  the  expense  of  added  computational  overhead  to  address  the  decision  processes 
associated  with  operating  the  hybrid  processing. 

How  does  one  select  an  appropriate  architecture  for  a  fusion  system?  This  is  a  basic  problem  in  system 
engineering.  Steinberg  and  Bowman  [83]  provide  basic  guidelines  for  system  design  and  architecture 
selection.  Bowman  in  particular  has  developed  an  approach  that  involves  a  hierarchical  decomposition  of 
fusion  system  into  nodes  with  an  allocation  of  functions  to  nodes  based  on  the  characteristics  of  the 
sensors,  communications,  and  processing  systems.  The  system  designer  should  explicitly  consider 
alternative  architectures  for  the  fusion  system  to  be  designed.  Each  alternative  can  be  modeled  to 
evaluate  the  system  effectiveness  and  the  demands  on  system  resources  such  as  computing  and 
communications. 
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Algorithm  selection  -  Perhaps  the  most  controversial  issue  in  data  fusion  is  the  selection  of  algorithms. 
There  are  many  algorithms  that  can  be  applied  to  the  different  processes  within  the  data  fusion  process. 
For  example,  many  different  algorithms  have  been  developed  for  target  tracking  and  target  identification. 
Even  for  a  function  as  basic  as  data  correlation,  a  wide  variety  of  techniques  can  be  applied.  Llinas  et  al 
[69]  identified  over  50  different  techniques  used  for  data  correlation  and  association.  The  methods 
involve  different  assumptions  concerning  the  nature  of  the  input  data,  understanding  of  the  uncertainty  of 
the  input  data,  available  computing  resources,  and  other  factors. 

One  challenge  in  the  implementation  of  a  data  fusion  system  is  how  to  select  from  these  different 
techniques.  Hall  and  Linn  [41]  provide  some  general  guidelines  for  the  selection  of  data  fusion  algorithms. 
However,  there  is  no  prescription  that  provides  a  unique  specification  of  which  algorithms  to  use. 
Unfortunately,  many  proponents  of  specific  techniques  (e.g.,  Bayesian  inference,  Dempster-Shafer’s 
method,  multiple-hypothesis  tracking,  etc.)  argue  that  their  method  is  the  only  method  to  be  used  for 
every  application.  The  choice  of  a  set  of  algorithms  for  a  fusion  system  must  be  based  on  a  system’s 
engineering  approach.  The  designer  must  have  a  clear  understanding  of  the  algorithms  (including  the 
underlying  assumptions,  required  a  priori  data,  etc.),  the  processing  constraints  of  the  fusion  system,  and 
the  limitations  in  the  observing  environment.  In  some  cases,  sophisticated  algorithms  may  be 
mathematically  appealing,  but  cannot  be  effectively  used  because  the  requisite  a  priori  data  is  not 
available.  Hall  and  Linn  [41]  provide  an  example  of  how  easily  complex  algorithms  can  be  corrupted  by 
input  of  incorrect  data.  Special  care  must  be  taken  to  understand  how  fragile  an  algorithm  is  to  variations 
in  the  input  data.  A  recommended  approach  is  to  deliberately  identify  and  tradeoff  candidate  algorithms 
prior  to  the  selection  of  an  algorithm  suite  for  a  data  fusion  system. 

Software  implementation  -  Implementation  of  a  data  fusion  system  generally  involves  development  of  an 
extensive  set  of  software.  Use  of  COTS  [53];  care  must  be  taken  not  to  follow  the  trap  of  using  too  much 
existing  data  fusion  software;  In  general  these  are  “point  solution”  and  not  particularly  portable  to  other 
applications.  There  does  not  exist  the  equivalent  of  a  numerical  methods  library  for  data  fusion  (although 
there  are  some  tool  kits  -  Khoros  and  the  data  fusion  tool  kit).  In  typical  implementations  the  bulk  of  the 
software  will  be  for  the  infrastructure. 

Test  and  evaluation  (T&E)  -  T&  E  involves  the  traditional  problems  of  testing  and  evaluating  large-scale 
hardware  and  software  systems.  Special  challenges  for  evaluating  data  fusion  systems  include;  (1) 
evaluating  single  versus  multiple  sensor  performance,  (2)  evaluation  the  effectiveness  of  context-based 
reasoning,  (3)  obtaining  sufficient  training  data  for  pattern  recognition  algorithms,  and  (4)  understanding 
how  data  fusion  performance  is  affected  by  varying  performance  sensors. 

Hall,  Kasmala  and  colleagues  [40]  developed  a  visual  programming  data  fusion  tool  kit.  This  tool  kit 
supports  rapid  prototyping  and  experimentation.  The  tool  provides  a  collection  of  algorithms  for  signal 
conditioning,  feature  extraction,  and  data  fusion.  It  has  been  applied  to  CBM  data  including  gearbox  data, 
data  from  NASA  Ames  Research  Center  wind  tunnel  equipment,  and  data  collected  from  a  rotorcraft 
gearbox.  The  tool  provides  a  “point  and  click”  graphical  interface  for  creation  of  processing  flows, 
selection  of  algorithms,  and  display  of  output  results.  The  top  level  graphical  interface  is  shown  in  Figure 
5.2. 


86 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Interim  Report  (2/3) 


Figure  7.4.1:  Penn  State  ARL's  Multisensor  Fusion  Toolkit. 


7.4.3  Condition-Based  Monitoring 

Development  of  technology  to  enable  the  implementation  of  condition-based  maintenance  for  mechanical 
systems  is  of  vital  importance  to  the  department  of  defense  and  the  navy.  Maintenance  and  overhaul  of 
large  platforms  and  weapon  systems  such  as  the  CVN-76  comprise  over  35  per  cent  of  the  projected  life- 
cycle  cost.  This  exceeds  the  original  platform  design  and  development  costs.  The  ability  to  monitor  the 
health  of  mechanical  equipment  and  to  accurately  predict  remaining  useful  life  will  allow  a  major  reduction 
in  maintenance  costs  while  simultaneously  increasing  safety  and  improving  mission  readiness  for  key 
assets. 

The  importance  of  accurate  health  assessment  and  prediction  for  electrical  and  mechanical  systems  has 
been  cited  in  numerous  national  defense  plans  and  studies.  For  example,  the  1996  United  States 
Defense  Technology  Plan  objectives  included  an  80%  reduction  in  aircraft  mechanical  mishaps  and  a 
35  %  reduction  in  spare  parts  inventories.  A  1995  OASN  study  on  safety  and  survivability  of  aircraft 
recommended  a  need  to  achieve  a  30  %  reduction  in  lifecycle  maintenance  costs.  Multiple  safety  reports 
have  identified  the  impact  of  undetected  maintenance  problems  that  resulted  in  the  loss  of  life  for  military 
personnel.  A  1996  United  States  Air  Force  Integrated  Product  Team  report  identified  58  preventable 
mishaps  resulting  in  the  loss  of  16  lives  and  an  equipment  cost  of  $  365  M. 

Two  recent  documents  cite  the  need  to  accelerate  the  application  of  embedded  diagnostics  and 
condition-based  maintenance.  The  U.  S.  Army  VcoS  memorandum,  dated  April  30  1998,  assert  that,  "... 
include  embedded  diagnostics  on  all  new  and  retrofit  equipment..."  The  memorandum  further  states,  "... 
We  will  not  field  systems  or  retrofit  equipment  without  embedded  diagnostics.  If  a  tradeoff  must  be  made 
because  of  funding,  Army  policy  will  be  to  obtain  fewer,  more  capable  systems.”  The  US  Navy 
OPNAVINST  4700.16-policy  document  on  Condition-Based  Maintenance  dated  May  6  1998  establishes  a 
navy  policy  to  implement  CBM.  The  document  asserts  that,  “CBM  Methodology  shall  be  used  to 
determine  maintenance  decisions  and  reduce  scheduled  maintenance  and  manpower  requirements.” 
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The  policy  also  indicates  that,  “Chief  of  Naval  Operations  (CNO)  will  fund  naval  programs,  processes,  and 
enabling  technologies  proven  applicable  and  effective  in  supporting  the  maintenance,  manning,  and  cost 
reduction  objectives  of  this  instruction.” 

CBM  has  enormous  commercial  application  for  the  transportation  and  manufacturing  industries. 
Demonstration  of  CBM  enabling  technology  will  provide  the  basis  for  improved  automobiles,  safer 
commercial  aircraft,  improved  automation  of  industrial  processes,  and  many  other  commercial 
applications.  Companies  such  as  Oceana  Sensor  Technology,  Honeywell,  Boeing,  Lockheed  Martin  and 
many  other  companies  are  investing  in  this  technology.  Commercial  products  will  include  new  sensors, 
health  monitoring  systems,  improved  automobiles  and  aircraft,  and  new  factory  automation.  Overall, 
CBM  technology  improvements  will  lead  to  increased  safety,  increased  productivity,  and  reduced  costs  of 
products. 

Implementation  of  condition-based  maintenance  involves  predictive  diagnostics  (i.e.,  diagnosing  the 
current  state  or  health  of  a  machine  and  predicting  time  to  failure  based  on  an  assumed  model  of 
anticipated  use).  CBM  and  predictive  diagnostics  depend  on  multisensor  data — such  as  vibration, 
temperature,  pressure,  and  presence  of  oil  debris— which  must  be  effectively  fused  to  determine 
machinery  health.  Indeed,  Hansen  et  al.  suggested  that  predictive  diagnostics  involves  many  of  the  same 
functions  and  challenges  demonstrated  in  more  traditional  DoD  applications  of  data  fusion  (e.g.,  signal 
processing,  pattern  recognition,  estimation,  and  automated  reasoning)  [54],  This  section  presents  the 
potential  for  technology  transfer  from  the  study  of  CBM  to  DoD  fusion  applications. 

CBM  involves  monitoring  the  health  or  status  of  a  component  or  system  and  performing  maintenance 
based  on  that  observed  health  and  some  predicted  remaining  useful  life  (RUL)  [23].  This  predictive 
maintenance  philosophy  contrasts  with  earlier  ideologies,  such  as  corrective  maintenance — in  which 
action  is  taken  after  a  component  or  system  fails — and  preventive  maintenance — which  is  based  on  event 
or  time  milestones.  Each  involves  a  cost  tradeoff.  Corrective  maintenance  incurs  low  maintenance  cost 
(minimal  preventative  actions),  but  high  performance  costs  caused  by  operational  failures.  Conversely, 
preventative  maintenance  produces  low  operational  costs,  but  greater  maintenance  department  costs. 
Moreover,  the  application  of  statistical  safe-life  methods  (which  are  common  with  preventative 
maintenance)  usually  leads  to  very  conservative  estimates  of  the  probability  of  failure.  The  result  is  the 
additional  hidden  cost  associated  with  disposing  of  components  that  still  retain  significant  remaining 
useful  life. 

Another  important  consideration  in  most  applications  is  the  operational  availability  (a  metric  that  is  popular 
in  military  applications)  or  equipment  effectiveness  (more  popular  in  industrial  applications).  High  total 
cost  is  incurred  when  overly  corrective  or  overly  preventative  maintenance  dominates.  These  also  provide 
a  lower  total  availability  of  the  equipment.  On  the  corrective  side,  equipment  neglect  typically  leads  to 
more  operational  failures  during  which  time  the  equipment  is  unavailable.  On  the  preventative  side,  the 
equipment  is  typically  unavailable  because  it  is  being  maintained  much  of  the  time.  An  additional  concern 
that  affects  availability  and  cost  in  this  region  is  the  greater  likelihood  of  maintenance-induced  failures. 

The  development  of  better  maintenance  practices  is  driven  by  the  desire  to  reduce  the  risk  of  catastrophic 
failures,  minimize  maintenance  costs,  maximize  system  availability,  and  increase  platform  reliability. 
These  goals  are  desirable  from  the  application  arenas  of  aircraft,  ships,  and  tanks  to  industrial 
manufacturing  of  all  types.  Moreover,  given  that  maintenance  is  a  key  cost  driver  in  military  and 
commercial  applications,  it  is  an  important  area  in  which  to  focus  research  and  development  efforts.  Such 
cost  savings  have  motivated  the  development  of  CBM  systems;  furthermore,  substantially  more  benefit 
can  be  realized  by  automating  a  number  of  the  functions  to  achieve  improved  screening  and  robustness. 

Extensive  research  has  been  performed  to  address  the  condition-based  maintenance  problem.  Research 
has  included  work  in  advanced  sensors,  signal  processing,  multi-sensor  data  fusion,  automated 
reasoning,  mechanical  models,  and  non-linear  dynamics.  Indeed,  similar  research  was  conducted  at  the 
Pennsylvania  State  University  funded  by  the  Office  of  Naval  Research  under  the  auspices  of  a  Multi¬ 
disciplinary  University  Research  Initiative  (MURI)  program  on  Integrated  Predictive  Diagnostics  ( IPD). 
Information  on  this  project  may  be  found  at  the  web  site: 
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www. arl  psu.edu/areas/soa/cQnditionmaint.htmL 

This  site  contains  a  summary  of  the  research  and  list  of  publications.  Various  assessments  of  the  state  of 
the  art  in  condition-based  maintenance  have  been  conducted.  See  for  example  the  work  by  Hall  [58]  and 
by  Byington  and  Garga  [16].  Additional  information  is  provided  by  Kumara  et  al  [64],  [15],  [73],  and  [87], 

7.4. 3.1  Constituents  of  a  CBM  System 

CBM  uses  sensor  systems  to  diagnose  emerging  equipment  problems  and  to  predict  how  long  equipment 
can  effectively  serve  its  operational  purpose.  The  sensors  collect  and  evaluate  real-time  data  using  signal 
processing  algorithms.  These  algorithms  correlate  the  unique  signals  to  their  causes — for  example, 
vibration  sideband  energy  created  by  developing  gear  tooth  wear.  The  system  alerts  maintenance 
personnel  to  the  problem,  enabling  maintenance  activities  to  be  scheduled  and  performed  before 
operational  effectiveness  is  compromised. 

The  key  to  effectively  implementing  CBM  is  the  ability  to  detect,  classify,  and  predict  the  evolution  of  a 
failure  mechanism  with  sufficient  robustness — and  at  a  low  enough  cost — to  use  that  information  as  a 
basis  to  plan  maintenance  for  mission-  or  safety-critical  systems.  “Mission  critical”  refers  to  those  activities 
that,  if  interrupted,  would  prohibit  the  organization  from  meeting  its  primary  objectives.  “Safety  critical” 
functions  must  remain  operational  to  ensure  the  safety  of  humans  (e.g.,  airline  passengers).  Thus  a  CBM 
system  must  be  capable  of: 

•  Detecting  the  start  of  a  failure  evolution 

•  Classifying  the  failure  evolution 

•  Predicting  remaining  useful  life  with  a  high  degree  of  certainty 

•  Recommending  a  remedial  action  to  the  operator 

•  Taking  the  indicated  action  through  the  control  system 

•  Aiding  the  technician  in  making  the  repair 

•  Providing  feedback  for  the  design  process 

These  activities  represent  a  closed-loop  process  with  several  levels  of  feedback,  which  differentiates 
CBM  from  preventive  or  time-directed  maintenance.  In  a  preventive  maintenance  system,  time  between 
overhaul  (TBO)  is  set  at  design,  based  on  failure  mode  effects,  criticality  analyses  (FMECA),  and 
experience  with  like  machines’  mortality  statistics.  The  general  concept  of  a  CBM  system  is  shown  in 
Figure  5.3. 
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Figure  7.4.2  Concept  of  a  Health  Monitoring  System. 


The  intelligent  monitoring  system  shown  in  Figure  5.3  has  multiple  components  and  functions  including; 
(1)  active  and  passive  sensors,  (2)  signal  processing  and  feature  extraction,  (3)  pattern  classification,  (4) 
multi-sensor  data  fusion,  (5)  automated  reasoning,  (6)  models,  (7)  historical  data  input,  (8)  mission 
constraints,  and  (9)  human-in-the-loop  decision  making. 


Active  and  passive  sensing  -  Many  different  active  and  passive  sensors  are  applicable  for  monitoring  a 
mechanical  system.  Impending  failure  conditions  cause  excessive  vibration  ([95],  [12]),  noise,  heat, 
debris  in  lubricants  ([1],  [79],  [20]),  and  other  symptoms  such  as  acoustic  emissions.  As  might  be 
anticipated  a  wide  variety  of  sensors  have  been  utilized  to  monitor  such  systems.  Unfortunately,  there 
are  a  number  of  challenges  in  sensing.  First,  while  mechanical  failure  is  initiated  at  a  materials  level, 
typical  sensors  observe  the  results  at  a  subsystem  or  platform  level.  Figure  5.4  illustrates  the  hierarchy 
from  the  material  level  (where  failures  are  initiated)  and  the  subsystem  to  platform  levels  where  failure 
effects  are  observed. 
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Figure  7.4.3  Material  to  Platform  Hierarchy 


Byington  and  Garga  [16]  describe  an  experiment  performed  with  a  simple  two-gear  mechanical  gearbox 
(called  the  mechanical  diagnostic  test  bed).  In  multiple  experiments,  a  two-gear  box  rated  at  10 
horsepower  was  systematically  overloaded  using  a  30  horsepower  motor  and  an  applied  70  horsepower 
load.  The  gearbox  was  fitted  with  approximately  50  sensors  including  accelerometers,  microphones,  and 
torque  meters.  Information  about  this  experimental  test  bed  can  be  found  at  the  web  site: 

http://www.arl.psu.edU/areas/soa/facilitiestools.html#Mechanical. 

Under  controlled  conditions,  gearboxes  were  systematically  driven  to  failure.  Even  though  the  load 
conditions  were  identical  and  the  sensors  were  placed  in  identical  locations  on  the  gearboxes,  the  output 
from  the  sensors  differed  markedly  from  one  transmission  to  another.  Apparently,  minor  differences  in 
the  gearbox  housings  acted  as  a  non-linear  amplifier  to  result  in  significantly  different  readings  from  the 
sensors  from  one  test  run  to  another.  Hence  the  idea  of  using  a  simple  threshold  scheme  to  monitor 
excess  vibration  is  not  a  reliable  means  for  detecting  failure  conditions. 

Signal  processing  and  feature  extraction  -  The  observational  environment  for  intelligent  monitoring 
systems  can  very  challenging.  For  example  the  ambient  vibration  on  a  rotorcraft  is  nearly  1000  gs.  The 
differentia!  vibration  associated  with  an  incipient  gear  tooth  crack  may  only  be  %  to  1  g.  Hence,  the  signal 
to  be  detected  has  a  1000  to  1  noise  to  signal  ratio.  Moreover,  the  vibrations  associated  with  a  rotorcraft 
transmission  involve  the  fundamental  and  harmonic  frequencies  of  tens  of  gear  meshes.  In  general  the 
signals  observed  by  monitoring  sensors  are  very  complex  and  corrupted  by  noise  and  interfering  signals 
([36],  [70],  [92]).  Hence,  extensive  signal  processing  may  be  performed  to  reduce  noise,  focus  on 
frequencies  or  segments  of  interest,  and  perform  feature  extraction.  Numerous  features  have  been 
utilized  for  condition  monitoring  including  features  in  the  time  domain,  frequency  domain,  and  the  time- 
frequency  domain. 

Pattern  classification  -  After  the  sensor  data  are  conditioned  and  features  are  extracted,  then  pattern 
recognition  techniques  such  as  neural  networks  may  be  used  to  perform  fault  detection  and  identification. 
While  numerous  pattern  recognition  methods  have  been  applied  to  monitor  mechanical  systems,  the  key 
to  success  involves  selection  of  robust  features.  One  problem  in  such  selection  is  that  features  useful  in 
so-called  seeded  fault  experiments  may  be  brittle  or  fragile  in  failure  transition  experiments  ([71],  [47],  [17], 
[18],  [31],  and  [46]).  Seeded  fault  experiments  involve  comparing  the  results  of  a  normal  or  no-fault 
machine  with  the  observations  from  a  machine  in  which  a  fault  condition  has  been  deliberately  planted  (or 
seeded).  By  contrast,  transition  experiments  attempt  to  observe  the  behavior  of  a  feature  vector  as  a 
machine  transitions  from  normal  operation  to  a  failure  condition  (e.g.,  induced  by  overstressing  the 
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machine).  In  general,  fault  classification  based  on  information  from  a  single  sensor  tends  to  be 
ambiguous  with  the  potential  for  a  high  false  alarm  rate. 


The  concept  of  feature  extraction  and  pattern  recognition  for  fault  classification  is  illustrated  in  Figure  5.5 
below. 


<=> 


AO 

A  1 

Dimension 

An 

Reduction 

<=> 


Classifier 


Figure  7.4.4  Concept  of  signal  processing  and  pattern  classification  for  fault 

identification 


Data  from  a  sensor  such  as  an  accelerometer  are  processed  using  one  or  more  signal  processing 
algorithms  (e.g.,  extraction  of  Fourier  coefficients,  computation  of  auto-regression  (AR)  coefficients, 
wavelet  transformations  or  other  methods).  Subsequently  a  feature  vector  is  computed  (e.g.,  a  vector  of 
Fourier  coefficients).  This  feature  vector  is  input  to  a  classifier  such  as  a  neural  net  or  clustering 
algorithm.  Ideally,  the  feature  vector  can  be  mapped  into  separate  locations  in  feature  space,  with  each 
location  corresponding  to  a  different  fault  condition  (or  to  an  indication  of  equipment  health).  This  is 
illustrated  in  the  right  hand  side  of  Figure  5.5.  In  practice  there  are  many  issues  with  this  approach. 
Selection  of  appropriate  features,  collection  and  utilization  of  training  data  and  choice  of  classifier  are  all 
challenging  problems  (see  for  example,  [31],  [46],  [27],  and  [57]).  Typically  there  is  never  sufficient 
training  data  to  develop  a  robust  classifier.  Hence,  ad  hoc  substitution  methods  are  used  to  generate  a 
synthetically  large  training  set. 

Multi-sensor  fusion  -  It  is  intuitive  that  the  use  of  multiple  sensors  would  improve  the  ability  to  determine 
the  health  of  a  mechanical  system  and  to  predict  time  to  failure.  Improved  results  should  be  obtained  by 
expanding  the  physical  baseline  of  observations  and  also  from  combining  information  from  multiple 
sensors  of  the  same  type.  Indeed,  experiments  conducted  at  The  Pennsylvania  State  University  under  a 
Multidisciplinary  University  Research  Initiative  grant  funded  by  the  Office  of  Naval  Research  confirm  these 
anticipated  benefits  (see  [20],  [35],  [39],  [21],  [16]).  Fusion  can  be  performed  at  a  variety  of  levels  from 
fusion  of  raw  data  to  feature-level  and  decision-level  fusion.  Byington  and  Garga  [16]  provide  details  on 
algorithms  for  fusion  at  all  of  these  levels.  The  experiments  demonstrate  that  data  fusion  can  improve 
the  accuracy  of  fault  classification,  reduce  false  alarms,  and  partially  mitigate  the  effect  of  poorly 
performing  sensors. 

Automated  reasoning  -  Context-based  reasoning  is  important  to  assist  in  the  monitoring  process.  Real 
mechanical  systems  undergo  numerous  changes  during  their  operation  (e.g.,  during  the  course  of  a 
mission  and  during  their  life  span).  Symptoms  that  are  meaningful  during  one  part  of  a  mission  are 
meaningless  during  another  part.  An  example  is  the  vibrations  experienced  during  an  aircraft  takeoff  or 
landing  versus  level  flight.  Hence,  the  output  of  sensors  and  pattern  recognition  or  fusion  algorithms 
cannot  simply  be  taken  at  face  value.  Instead  the  use  of  automated  reasoning  assists  in  interpreting  the 
results  (see  for  example,  [47]).  Implicit  reasoning  techniques  such  as  neural  networks  or  pattern 
classifiers  have  been  applied  for  fault  detection  and  classification.  In  addition,  explicit  reasoning 
techniques  such  as  fuzzy-logic  rule  systems,  parametric  templates,  and  case-based  reasoning  methods 
have  also  been  applied.  Garga  et  al  ([35],  [47])  have  developed  hybrid-reasoning  methods  to  improve  the 
performance  of  both  explicit  and  implicit  reasoning  methods.  In  addition,  Hall  et  al  [48]  have  argued  that 
the  use  of  negative  reasoning  (viz.,  reasoning  about  information  that  is  not  observed  or  conditions  that  do 
not  appear  to  be  occurring)  can  improve  the  diagnosis  of  mechanical  systems.  They  point  out  that  expert 
diagnosticians  often  use  negative  reasoning. 

Modeling  -  In  order  to  understand  the  condition  of  a  system  and  to  predict  future  evolution,  models  of  the 
system  being  monitored  are  required.  Ideally,  models  should  include  information  about  the  machine 
construction  and  makeup,  the  transformations  from  platform-induced  demands  to  materials  level  effects. 
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Models  should  allow  prediction  of  observations  based  on  hypothesized  fault  conditions  (observation 
models).  Finally,  dynamic  models  are  sought  to  support  prediction  of  the  system  evolution  (viz.,  state 
transition  models).  Unfortunately,  such  models  rarely  exist.  Much  work  has  been  performed  to  develop 
materials  level  models  (e.g.,  crack  growth  models,  stress/strain  models,  and  finite-element  models  [127]). 
However,  there  are  no  general  models  to  link  materials  phenomena  to  platform  results,  or  to  predict 
observations  from  hypothesized  failure  conditions.  Finally,  system-level  failure  evolution  models  do  not 
exist.  Hence,  it  is  necessary  to  combine  limited  physics-based  models  with  more  ad  hoc  models  based 
on  the  experience  of  trained  mechanic  (see  [25],  [8],  [9],  [7],  [10],  [26]). 

Historical  data  input  -  Historical  maintenance  information  and  information  about  the  previous  missions 
and  system  use  can  be  used  to  assist  in  interpreting  the  current  state  and  prediction  of  future  conditions. 
An  aircraft  that  has  been  utilized  for  routine  flights  may  have  a  significantly  different  condition  than  an 
aircraft  flown  on  combat  missions  -  even  though  they  nominally  have  experienced  the  same  number  of 
flight  hours.  Moreover,  long-term  data  such  as  oil  debris  analysis  may  be  useful  to  interpret  the  condition 
and  evolution  of  a  machine.  Byington  and  Garga  [16]  point  out  that  for  mechanical  systems  such  as 
gearboxes,  the  morphology  of  wear  particles  in  circulating  oil  is  different  for  benign  wear  compared  to 
those  generated  by  the  active  wear  associated  with  pitting,  abrasion,  scuffing,  fracturing  and  other 
abnormal  conditions.  Roylance  and  Raadnui  [80],  for  example,  correlated  particle  features  (quantity,  size, 
composition  and  morphology)  with  wear  characteristics  (severity,  rate,  type,  and  source). 

Mission  constraints  -  A  key  for  military  systems  is  mission  constraints.  While  commercial  systems  may 
be  able  to  accept  recommendations  for  maintenance,  during  military  operations  mission  constraints  may 
severely  limit  the  possible  maintenance  or  mitigation  actions.  Hence,  mission  constraints  and  information 
must  be  considered  when  performing  context-based  reasoning  about  a  system  being  monitored. 

Human-in-the-loop  decision-making  -  Despite  advances  in  intelligent  monitoring  systems,  there  remains 
a  role  for  the  human  to  act  as  a  decision-maker.  The  pilot,  system  operator,  or  maintenance  technician 
may  be  involved  in  interpreting  the  results  of  the  intelligent  monitoring  system  and  making  final  decisions 
related  to  system  operation  or  maintenance.  The  definition  of  this  role  is  part  of  the  overall  systems 
engineering  process  in  designing  a  system.  For  military  systems  in  particular,  it  is  desired  for  a  human 
operator  to  be  capable  of  overriding  recommendations  by  an  intelligent  monitoring  system  in  order  to 
accomplish  a  mission  (even  when  the  act  of  override  may  endanger  equipment).  Byington  et  al  [19] 
provides  an  excellent  discussion  of  these  issues  as  they  relate  to  flight  crews. 
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